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ABSTRACT 


Network-centric warfare (NCW) is the Navy’s central concept for organizing its efforts to 
transform itself for military operations in the 21st Century. This concept li nk s together 
Navy ships and shore sites into highly integrated networks to provide geographically 
dispersed war fighters and decision makers real-time information exchange at every level. 

As the Navy continues its efforts to align network operations, the existing IT 
structure is falling short in meeting the war fighter requirements. Interoperability among 
DON networks is critical to improve combat capability and efficiency. Navy war fighters 
require seamless access to IT services while deployed anywhere in the world. The 
Embarkables process provides the ability for users to move their workstation between 
networks but consists of a complex and time consuming IT process when transitioning 
from shore facilities and to ship environments. This thesis identifies root causes for 
network interoperability problems faced by embarking units when connecting to alternate 
networks, in this case the information technology for the 21st Century environment. This 
thesis also recommends approaches to improve integration of ashore assets into the 
shipboard environment, and suggests further areas of research for a seamless user 
experience moving across networks. 
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EXECUTIVE SUMMARY 


Successful military missions rely on secure, reliable, available communication networks 
anytime, anywhere. The current Naval networking environment is composed of four 
enterprise networks (NMCI, ONE-NET, IT-21 and MCEN) supporting over half a 
million Navy and Marine service men and women around the world executing these 
missions. These networks are becoming large complex systems with relatively stable 
architectures, with no standardization of technologies or protocols, with variations of 
security policies and requirements, and with significant architectural differences resulting 
in network interoperability challenges, and degradation and loss of communication 
efficiency of mobile users. 

As the Department of Defense (DoD) strives for network commonalty and 
alignment, immediate capabilities are needed to support deploying forces anywhere in the 
world. Embarkables provide mobile Navy and Marine assets the ability to integrate into 
the IT-21 environment for multiple deployment scenarios, but the diversity of operational 
environments and Embarkables processes result in cumbersome and time consuming 
integration problems. 

This thesis provides an overview of existing Embarkables mechanisms and 
identifies gaps in IT services and capabilities available to ashore systems while connected 
to the IT-21 topology. It identifies possible contributing factors to the management 
deficiency of Embarkables workstations, such as the decentralized network management 
afloat model, the variation and incompatibility of management tools and the high failure 
rate of patch downloads due SATCOM constraints. 

In additional to the network management interoperability issue, DoD security 
mandates such as Hosted Base Security System (HBSS) introduce challenges to the 
integration of ashore assents into the afloat network. Solutions driven by these security 
mandates include multiple agents managing communication between workstations and 
policy enforcing servers, client firewalls configured with policies for inbound and 
outbound traffic specific to each network, and agents to perform scan of configuration 



settings. Embarking units cannot access their native network HBSS servers and are not 
compatible with the ship’s HBSS servers and policies. This deficiency requires manual 
processes to install and uninstall various instances of HBSS. 

Active Directory (AD) structures are analyzed to determine how the operational 
environments and system requirements influenced present architectural designs. Navy 
ships’ operational environment utilizing satellite communication adds the requirement for 
each ship to be self-sustained while at sea. This decentralized, multi-forest network 
management model meets its purpose of providing data isolation and prevents network 
asset mobility or integration from any other domain by preventing any data sharing, 
replication, and collaboration with other IT-21 ships or with the ashore networks. 
Alternatively, wired ashore networks offer superior performance and reliability. NMCI 
and ONE-NET share a similar AD model of a single forest, fully meshed structure 
allowing continued replication at the enterprise level. This AD structure provides 
centralized identification and authentication control, allowing user and seat mobility 
between logical and physical sites. 

The author provides recommendations for more efficient and prompt integration 
of ashore assets into the shipboard environment by (1) testing all ashore solutions against 
the Embarkables process prior to fielding to the operational environment, (2) adapting 
existing solutions to provide “office like” services to embarking users such as an 
enhanced DSTB solution currently accredited and in operation on NMCI, and (3) 
exploring new technologies such as enterprise services (individually or as a bundle) such 
as e-mail services, by fully or partially outsourcing these services to a third party. 

In summary, the Embarkables mechanisms support the Navy’s need to deploy 
personnel and equipment for military training, humanitarian, and combat mission 
operations as an interim fix to today’s network interoperability issues. 

As DoD aligns systems and resources across organizations and military services, 
enterprise systems must be flexible, adaptable and reconfigurable. Whether developing 
new solutions or upgrading operational networks, system architects and engineers must 
implement a system-of-system approach and focus on developing dynamic 



reconfigurable system architectures, with standardized protocols and technologies to 
enable adaptable and interoperable reliable systems to function anytime, anywhere. 
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I. 


INTRODUCTION 


A. BACKGROUND 

The concept of Network-Centric Warfare (NCW) is the Department of Defense 
doctrine for organizing its efforts to transform itself for 21st Century military operations 
by leveraging technical advances in information technology and telecommunications to 
improve military operations and increase combat power. The NCW concept li nk s 
together Navy ships and shore sites into highly integrated networks to provide 
geographically dispersed war fighters and decision makers real-time information 
exchange between every level of echelon in the joint military hierarchy needed to 
effectively execute U.S. military missions (Department of the Navy Chief Infonnation 
Officer, 2008). 

FORCEnet is the Department of the Navy (DON)’s vision of implementing NCW. 
Its objective is to integrate data, commands and capabilities into a single naval intranet to 
seamlessly and effectively share tactical information among the afloat and ashore forces. 
Under the Naval Network Warfare Command (NETWARCOM) governance, the Navy is 
implementing the FORCEnet doctrine by consolidating legacy networks into highly 
reliable, more secure centralized networks. Key Navy programs implementing the 
FORCEnet doctrine are: the Infonnation Technology for the 21st Century (IT-21) 
program, also known as Integrated Shipboard Network System (ISNS); the Navy-Marine 
Corps Intranet (NMCI); and the Base Level Information Infrastructure (BLII) Outside the 
Continental United States (OCONUS) Navy Enterprise Network (ONE-NET). These 
three networks service most Navy and Marine users in the Unites States onboard U.S. 
Navy vessels and OCONUS. 

As the FORCEnet concept, depicted in Figure 1, continues guiding and shaping 
the future of naval command and control communications, IT-21, NMCI and ONE-NET 
networks have linked over 16 major OCONUS Navy sites, 400 CONUS Navy and 
Marine locations, and almost 200 surface ships. They provide secure and non-secure IT 
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capabilities and services to over 827,000 users, 375,000 workstations and transport of 
more than 125 million e-mails each month. 



Figure 1. FORCEnet Concept Diagram (From Department of the Navy Chief 

Information Officer, 2008) 


As U.S. military forces deploy every day all around the globe, approximately 
100,000 war fighters require reliable network communications and access to IT data and 
services for efficient military operation support while deployed at any dispersed Navy 
and Marine location. Interoperability among the three networks is a critical element to 
provide continuous IT services to deployed units and to improve Navy combat power and 
information superiority (Runyan, 2006). 

There are Navy wide efforts to improve network interoperability, but the 
immediate need to embark NMCI and ONE-NET systems into the IT-21 environment has 
driven the emergence of the Embarkables mechanisms currently in operation. These 
Embarkables mechanisms (also called Deployables) provide the capability for ashore 
users to move their workstations and data to the afloat environment to receive basic IT 
services, but the integration of systems into the IT-21 topology involves complex and 
time consuming IT processes. 

The three networks have unique Embarkables requirements and capabilities based 
on their mission (Rivera, Deployables STEAG Brief, 2009). These high-level 
Embarkables requirements are summarized below: 

• IT-21 
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o Not required to deploy to NMCI or ONE-NET environments 
o Required to support integration of NMIC and ONE-NET 
users/workstations 

• NMCI 

o Requirement to deploy to IT-21 and ONE-NET environments 
o Not required to support integration of ONE-NET or IT-21 
users/ workstations 

• ONE-NET 

o Requirement to deploy to IT-21 environment 
o Required to support integration of NMCI users/workstations 
Figure 2 illustrates the high-level Embarkables requirements framework. 



IT-21 


ONE-NET Requirement to deploy 
IT-21 supports integration 





No requirementto deploy 
No integration support 


NMCI Requirementto deploy 
ONENET support® Integration 


NMCI Requirementto deploy 
IT-21 supports integration 


NMCI 


NAVY MARINE CORPS INTRANET 


Figure 2. High Level Embarkables Requirements (From Rivera, Deployables 

STEAG Brief, 2009) 


IT-21, NMCI and ONE-NET currently service different regions, operate 
independently from each other, consist of different architectures, are bound to different 
security and accreditation requirements, and implement different Embarkables 
procedures on deployed units. The result is a variation of the Embarkables process and 
deficiencies across the enterprise. 
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B. PURPOSE 

The purpose of this thesis is to identify the Embarkables operational 
requirements; investigate the current Embarkables processes, their shortcomings and 
challenges; and identify potential root causes, technical and/or programmatic, for existing 
Embarkables issues in order to provide recommendations to improve ashore asset 
integration into the afloat network, so that embarking staffs and users face a minimal 
amount of effort and time to access Navy IT resources and services during deployment. 

C. RESEARCH QUESTION 

The following questions are addressed in this thesis: 

• What are Embarkables and what are the challenges they currently face? 

• What are the requirements for the deployed users/systems for each 
network? 

• What is the impact of different desktop configurations? 

• What are the network management and architecture differences? 

• How can the Navy users better and quicker integrate their deployed 
systems into afloat domains? 

• How can the Navy users better and quicker integrate their deployed 
systems into all Navy domains? 

• How can seamless e-mail access be achieved? 

D. BENEFITS OF STUDY 

The Navy’s desired goal is the interoperability of NMCI and ONE-NET 
embarked users and workstations in the IT-21 environment in order to reduce the 
required reconfiguration of workstation and network devices, reduce administration 
overhead and maximize fleet efficiency while assets move between Navy network 
environments. 

This thesis identifies existing Navy mobile user requirements and challenges, 
provides an analysis of all Embarkables and integration mechanisms in place to integrate 
ashore assets into the afloat environment, and identifies potential causes for 
interoperability deficiencies. Identifying potential contributing factors causing integration 
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problems faced by embarking systems will facilitate the improvement and alignment of 
current processes to position the Navy so that embarking staffs and users face a minimal 
amount of effort and time to access Navy IT resources and services in all three 
environments. 

E. SCOPE AND LIMITATIONS 

The scope of this thesis is to identify the potential Embarkables root cause 
problems faced by the NMCI and ONE-NET mobile users and workstations connecting 
to IT-21 topology. 

This study includes an analysis of the current Embarkables processes and 
identifies each network’s organizational goals, operational requirements for mobile users, 
Embarkables processes and technology gaps including desktop image, network 
management and architecture differences. Because Embarkables requirements differ for 
IT-21, NMCI and ONE-NET as depicted in Figure 2, this thesis focuses on the NMCI 
and ONE-NET requirement to deploy to IT-21, and the requirement for IT-21 to support 
integration. 

F. METHODOLOGY 

The methodology used in this thesis research consists of: 

• Conduct literature review of IT-21, NMCI and ONE-NET system 
requirements for deployed systems 

• Conduct a review of Embarkables pre-deployment, deployment and post¬ 
deployment methods for all three networks 

• Perform application and software desktop solution analysis for the three 
networks. 

• Analyze the network management processes including patching and 
application distribution 

• Analyze the three different architectures from a programmatic and 
technical perspective 

• Develop recommendations for common Embarkables process across 
systems 
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II. 


NETWORKS OVERVIEW AND EMBARKABLES 
REQUIREMENTS 


A. INTRODUCTION 

The Department of the Navy continues defining and formulating the necessary 
steps to achieve a net-centric future for the Naval Networking Environment (NNE) in 
2016 while exploring and implementing solutions to resolve existing deficiencies and 
limitations for mobile users. These efforts have resulted in the implementation of various 
technical solutions and processes to enable IT services for mobile users connecting across 
naval network environments. 

This chapter provides an overview of the Navy’s vision for a highly 
interconnected enterprise networking capability; a synopsis of the existing networks, their 
mobile capabilities and requirements; and the existing Embarkables mechanisms to 
provide IT capabilities to the war fighter. 

B. THE NAVY’S VISION 

As defined on the NNE’s Concept of Operations, NNE “is an iterative set of 
integrated, phased programs that will guide the DON towards a future net-centric 
enterprise environment.” The NNE and Global Infonnation Grid 2.0 vision for DoD 
information superiority includes (Enterprise Services Working Group, 2010): 

• Single Sign-on 

• Anytime Anywhere Access to DoD Networks 

• Same e-mail for life (Home Station or Deployed) 

• Single DoD Directory (Global Access List) 

• Joint infrastructure 

• Common DoD policies and standards 

• Unity of command 

The DON’s strategy for the NNE initiative is to align networks across the 
enterprise, so that in the near future, those networks will be bound by a common 
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enterprise architecture, standards, and governance. There are several ongoing measures to 
aid and shape the planning for that future: (1) afloat networks such as IT-21, the 
Combined Enterprise Regional Information Exchange System-Maritime (CENTRIXS- 
M), the Sensitive Compartmented Information (SCI), and other legacy networks are 
being consolidated into the Consolidated Afloat Networks and Enterprise Services 
(CANES) starting in 2012; (2) legacy ashore networks continue migrating into ONE- 
NET; and (3) the fusion of NMCI and ONE-NET currently in progress to become the 
Next Generation Network (NGEN) by 2014. Figure 3 provides a graphical representation 
of the DON vision for the future of Navy networks including the Marine Corps Enterprise 
Network (MCEN) not covered in this thesis. The current Navy network environment 
consists of over 400 decentralized networks supporting over 800,000 users worldwide. In 
this multiple network environment, network interoperability is nonexistent, information 
sharing is limited, and resources and assets cannot be shared across networks. 

The Navy’s vision for a net-centric naval network environment is to consolidate 
and reduce the number of legacy networks, to increase DoD data sharing, and to increase 
network interoperability and communication efficiency. 


400+ Networks 
800.000+ Users 
425,000+ Workstations 



Figure 3. Naval Networking Environment (From Carey, 2010) 
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c. 


NETWORKS OVERVIEW 


Under NETWARCOM’s governance and operation, the Program Executive 
Offices (PEOs) oversee a portfolio of enterprise-wide IT programs designed to enable 
common business processes and provide standard IT capabilities to sailors at sea, 
Marines in the field and their support systems. The PEO for Command, Control, 
Communications, Computers and Intelligence (PEO C4I) oversees the afloat networks 
including IT-21. The PEO for Enterprise Information Systems (PEO EIS) oversees the 
ashore Navy networks NMCI and ONE-NET. 

1. IT-21 Network Overview 

IT-21 is the Navy’s investment strategy for procuring the desktop computers, data 
links, and networking software needed to establish an intranet for transmitting tactical 
and administrative data within and between Navy ships (Department of the Navy Chief 
Information Officer, 2008). IT-21 is a PEO C4I Program Manager, Warfare (PMW) 160 
product and it provides reliable, high-speed secret and unclassified network 
communications to Navy ships. The ship’s Local Area Network (LAN) hosts other 
systems such as Global Command and Control System - Marine Corps (GCCS-M), 
Naval Tactical Command Support System (NTCSS), Navy Standard Integrated Personnel 
System (DMS), and few other applications and systems. It enables voice, video, and data 
transmissions from a single desktop PC, allowing the war fighter to exchange tactical or 
non-tactical information (SPAWAR, 2011). IT-21 is a dynamic environment and consists 
of complex security and storage requirements with limited data reach-back access due to 
low bandwidth capacity. It performs identity management and application integration and 
can support multiuser workstations with the ability to customize their desktops. 

2. Navy Marine Corps Intranet 

NMCI is the DON shore-based enterprise network in the continental United States 

and Hawaii, providing a single integrated, secure IT environment for reliable, stable 

information transfer in both classified and unclassified environments. Previously owned 

and operated by contractor Electronic Data Systems (EDS) now Hewlett-Packard (HP), 

NMCI represents about 70 percent of all DON IT operations and it is the second largest 

9 



network in the world. NMCI’s implementation in 2001 dramatically improved network 
security across the enterprise while providing secure and non-secure voice, video, data 
communication and common computing environment (Department of the Navy Chief 
Information Officer, 2006). 

The NMCI contract ended on September 2010 and it was replaced by the 
Continuity of Services Contract (COSC). NMCI, now COSC, is a government owned and 
contractor operated network and it is managed by the Navy’s PEO EIS and supported by 
HP. For simplicity, the term NMCI will be used through this thesis but it also refers to 
COSC. 


3. ONE-NET Overview 

ONE-NET extends to most overseas Navy bases, posts, camps, stations, activities, 
and 14 major locations for an estimated user base of 40,000 Navy uniformed and civilian 
workforce members, including foreign nationals supporting the Navy facilities or joint 
military operations (Space and Naval Warfare Systems Center, 2010). It enhances 
system and software security and improved infonnation exchange capability among users 
in the OCONUS secure and non-secure environments and tactical/business partners in the 
deployed forces and Joint environment. Similarly to NMCI, it delivers comprehensive 
end-to-end information services through a common, secure computing and 
communications environment on both enclaves. ONE-NET is divided into three regions: 
Far East, Middle East and Europe. The three regions are logically connected to via the 
Defense Infonnation System Network (DISN) cloud and have centralized control 
authority. 

D. EMBARKABLES REQUIREMENTS 

As U.S. forces deploy around the world, approximately 100,000 war fighters 
require seamless access to enterprise IT services. Users temporally or pennanently move 
from one Navy network to another requiring continuity in core IT services in order to 
efficiently support the Fleet. This section investigates user network requirements based 
on high-level Embarkables requirements discussed in Chapter I and illustrated in 
Figure 2. 
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The only documented Embarkables requirements are addressed in the NMCI 
contract (N00024-00-D-6000) at a very high level, without target or threshold service 
requirements or key perfonnance parameters. Consequently, business rules had to be 
developed by the PEOs to establish mechanisms to support embarking units and to 
provide IT capabilities during deployments (Rivera, Deployables STEAG Brief, 2009). 
These mechanisms are technical and process workarounds to bridge the architectural and 
programmatic gaps resulting in Embarkables interoperability. These quick fixes partially 
alleviate the embarking unit’s network communication needs by providing some IT 
capabilities, but they do not provide seamless mobility between networks. 

1. Ashore Networks Embarkables Requirements 

NMCI and ONE-NET support a variety of Navy and Marine commands requiring 
frequent deployments to IT-21 environments. Embarking commands vary in size, 
deployment duration, and mission. These commands’ operations and mission success 
depend on reliable networks to access critical command and control, combat support and 
combat service support information in voice, video and data formats while deployed on 
an IT-21 environment. NMCI and ONE-NET require asset mobility to allow integration 
into a shipboard network and the ability to reintegrate back into their home network with 
none or minimal delay or lost of data. Both ashore networks require IT-21 to provide core 
services for short or extended periods of time during deployments. 

In addition to NMCI deploying into IT-21, NMCI requires the capability to 
integrate into ONE-NET to support Navy and Marine units deployed at OCONUS 
locations where ONE-NET is the Navy’s IT service provider. NMCI is not required to 
support integration of ONE-NET assets, and therefore ONE-NET users cannot connect to 
NMCI for services while in a CONUS location. NMCI requires reintegration of its users 
and workstations returning from IT-21 and from ONE-NET environments. 

At this time, ONE-NET does not deploy assets into NMCI but is required to 
support integration of NMCI assets into its topology for temporary deployments. ONE- 
NET requires reintegration of its users and workstations returning from IT-21. 
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NMCI and ONE-NET established unique processes to reintegrate their assets back 
into the network upon completion of deployment. Reintegration back into NMCI or 
ONE-NET is beyond the scope if this thesis and will not be further analyzed. 

2. Afloat Network Embarkables Requirements 

IT-21 does not deploy assets outside its network boundaries, therefore there is no 
requirement for the ashore networks to support integration of IT-21 assets into their 
topologies. The few exceptions are VIPs such as the Flag staff who deploy outside the IT- 
21 environment, but these users are outside the scope of this thesis. 

Users who transition from an IT-21 ship to another, or to an ashore Navy network 
are currently not able to seamlessly transfer their data or e-mail to an alternate network. 
Any data migration is a manual process using authorized external media. User accounts 
are disabled and deleted on the IT-21 network, and accounts are created on the new 
network. This is a troublesome manual process and results in loss of user data and 
productivity. 

Although IT-21 is not required to deploy assets, it is required to support user and 
seat integration from NMCI and ONE-NET. Marine Corps, Airwings, and other shore 
command deployments are tied to Navy ship deployments and depend on IT-21 for IT 
services. These commands require continuity of IT services by maintaining access to end 
user data, access to local servers and mail files to provide the war fighter communication 
effectiveness in a mobile environment. 

3. Users to Move Seamlessly between Networks 

Immediate integration into the afloat network is required for embarking users to 

efficiently operate onboard a ship. This seamless connection into an alternate network is 

currently not possible for ashore assets, therefore user IT capabilities must be provided by 

alternate means. User requirements and services for embarking units while connected to 

the IT-21 network are undefined. This section attempts to identify the Embarkables user 

IT capabilities needed while connected to the visitor network by assuming embarking 

units require the same capabilities they obtain as while they are connected to their native 

network. Capabilities provided by a home network are set as the baseline requirements 
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for a seamless transition to the visitor network. This assists identifying the Embarkables 
deltas and shortcomings by comparing the baseline against what embarking units 
capabilities received during deployments. 

A list of high level capabilities required by the NMCI network to its users is 
identified in Table 1. As users get deployed and are required to temporarily access the 
afloat network, most of these capabilities are not immediately restored, are degraded, or 
completely lost. 
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NEED ID 

USER NEEDS 

N1 

Cryptographic logon to workstation (cached users) 

N2 

Domain account 

N3 

Network access 

N4 

Send/Receive Email 

NS 

Attach and open email attachments 

N6 

Access to Contacts 

N7 

Access to Native Network Global Address List 

N8 

Ensure workstation protected from cyber attaches and spam 

N9 

Shared Calendar 

NIO 

Accessibility to user data and email files on local hard disk such as .pst files as part of user profile 

Nil 

Accessibility to user data and email files stored on the user home drive 

N12 

Outlook Capabilities (email settings, print styles, email rules and setting, etc) 

N13 

DOD digital email signature and encryption capability for home network email 

N14 

DOD digital email signature and encryption capability for host network email 

N15 

MS Office and Other local DoD approved apps for seat/user 

N16 

Protected data transmissions 

N17 

Web access and Cache 

N18 

Authentication Services—PKI/CAC 

N19 

OS and application patching 

N20 

Access to web based applications including certificate-based authentication applications 

N21 

Native Home drive to view, edit, crate and delete files depending on use access 

N22 

Native Command shared drive to view, edit, crate and delete files depending on use access 

N23 

Access to Public Folders 

N24 

Local and network data integrity 

N25 

Locate and connect to home and share drives 

N26 

Seat Local Data storage capacity 

N27 

Receive administrative policies and user privileges 

N28 

Security policies applied to account 

N29 

Application management 

N30 

Air Card and Wireless capability 

N31 

Print/Scan/Fax capabilities 

N32 

Locate and connect to printers 

N33 

Chat and Instant Messaging (IM) 

N34 

Access to collaboration tools (i.e. Defense Connect Online (DCO) 

N35 

Command Document collaboration / Portal (SharePoint) 

N36 

24/7 Help Desk 

N37 

Technical support 

N38 

Capability to create a trouble ticket and check status 

N39 

Training capabilities 

N40 

Tech Refresh 

N41 

HW repair or spares (PUK) 

N42 

Capability to transfer files 

N43 

Messaging—Alerts 

N44 

Secure, available and reliable network connection (99% Service Level Agreement) 

N45 

Backup and Restore Capability 

N46 

MAC (Move, Add, Change) Capability 

N47 

VTC capabilities 

N48 

Access to IT-21 Global Address List 

N49 

Access to IT-21 resources such as applications 

N50 

Ability to store to external media 

N51 

Produce and Manage Audio and Graphic Media 

N52 

Disconnect/Log out 

N53 

Ensure non repudiation 

N54 

Receive all Computer Network Defense policies and mandates (HBSS/DAR/etc) 


Table 1. Embarkables User Requirements Baseline (After NMCI, 2010; NMCI, 

2009) 
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The Navy has deployed some functional Embarkables mechanisms to support 
embarked units into IT-21 to provide some of the required IT services and capabilities 
and prevent loss in productivity and inefficiencies in any mission efforts. Such 
mechanisms are analyzed in detail in the next section. 

E. EMBARKABLES MECHANISMS OVERVIEW 

Prior to any Embarkables process implementation to integrate ashore assets into 
the afloat network, users were forced to leave behind all workstations and data storage 
servers on their native network, as those devices were not allowed to connect to the afloat 
network. As a result, access to users’ locally stored data and on shared network drives 
were not possible, requiring users to export all data into an external media (portable hard- 
drives, thumb drives, CDs) and carry onboard. E-mail files, user data and command 
shared data were not accessible during a deployment. 

In order to provide basic IT services, ships’ staff was required to create user 
domain accounts as for any other ship user. Hundreds of workstations had to be provided 
and maintained throughout the deployment period to support the embarking users. Upon 
completion of the deployment, all accounts were disabled and data created during the 
deployment transferred via an external media, or left behind and lost. This labor intensive 
process had to be repeated during every deployment. 

The Embarkables process (also known as Deployables) was established to support 
the Navy’s need to deploy personnel and equipment for military training, humanitarian, 
and combat mission operations as an interim fix to a more complex effort to align Navy 
networks. IT-21 currently supports embarking groups which vary in size, sometimes over 
900 users are deployed to a single carrier adding logistical challenges to provide 
workstations and IT support for large amount of users. 

1. IT-21 Embarkables Mechanisms 

IT-21 must support prompt integration of non IT-21 assets into its topology 
during deployments. Embarkables processes and mechanisms are implemented to 
integrate and support Navy and Marine embarking units for various scenarios. 
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U.S. Marine Corps deploy on amphibious warfare ships and aircraft carriers. IT- 
21 and the USMC have pennanently installed Pre-Position Servers (PPS) connected to 
the IT-21 topology as part of the Ship’s domain. Other scenarios involve Navy units 
embarking onboard IT-21 platforms bringing their own network storage servers, or single 
users with or without their workstations. These scenarios and the mechanism used for 
each are described in the following sections. 

2. NMCI Deployables Mechanisms 

NMCI employs various technical solutions across the enterprise to support NMCI 
users anywhere in the globe. These solutions include: Two Way Trust (TWT) between 
NMCI and ONE-NET; Deployable Site Transport Boundary (DSTB) Core; DSTB Fly 
Away Kit process; NMCI Deployables to IT-21, and current efforts for a Seamless Trust 
between NMCI and IT-21. Although not all mechanisms are employed on the IT-21 
environment, an overview of each of the NMCI deployables solution is provided below: 

a. Two Way Trust between NMCI and ONE-NET 

The AD two-way-trust between NMCI and OCONUS’ Navy networks 
enables users in either network to access shared resources and enables roaming users to 
reach back to their home network from the partner network. Through a trust, one partner 
can share its resources with users native to partner’s authentication infrastructure, 
avoiding the need to create separate accounts. This solution supports interoperability 
between NMCI and ONE-NET and is therefore outside the scope of this thesis. 

b. Deployable Site Transport Boundary (DSTB) Core 

The DSTB, also called “NMCI in a box,” provides office-like connectivity 
to NMCI assets while connected to a non-NMCI environment. It allows a small network 
footprint to reach NMCI resources from the field. The number of users it can support 
depends on the Wide Area Network (WAN) bandwidth and switch port capacity. It 
provides versatile WAN connectivity options: T1 (1.544Mbs), Digital Subscriber Line 
(DSL), Ethernet (lOMbs), ISDN (128K), Fiber (OC3-155Mbs). This capability allows all 
NMCI assets to operate seamlessly while connected to a host network. It is used for 


16 



transport services only, with minimal reconfiguration needed to integrate into the host 
network’s topology. The DSTB architecture consists of an inner router for LAN access, 
an outer router for WAN access, a VPN device to establish an encrypted tunnel back to 
the NMCI network, and a WAN accelerator for traffic prioritization and bandwidth 
optimization. 

DSTB provides IT services by local NMCI servers along with an 
appropriately security enforced backend connection to the host network for needed file, 
print, app, and web services. All network management functions are available via the 
Virtual Private Network (VPN) tunnel as illustrated in Figure 4. DSTB provides access to 
the NMCI network but does not provide access to the host network’s resources. 



DSTB 

Figure 4. DSTB Architecture (From Hewlett-Packard Development Company, 

2010) 

c. Deployable Site Transport Boundary Fly A way Kit 

Fly Away Kit is the downsized version of the standard DSTB and supports 
2-12 users and is mostly use for VIP personnel. 
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d. NMCI Deployables to IT-21 

The objective of the deployables process is to provide operational units the 
ability to be self-sufficient while in a deployed status on an IT-21 environment. This 
mechanism is implemented on the unclassified network and it allows embarking ashore 
personnel to utilize the host environment’s network backbone to perform their mission. 

U.S. Marines frequently embark on Navy ships to conduct operations from 
beyond territorial waters. Some Marine fixed-wing squadrons are assigned to Carrier 
Airwings or amphibious warfare ships to train and operate along with Navy commands. 
These platforms have pre-deployed server equipment already installed and configured to 
support embarked Marine units. These PPS suites are installed on a separate domain 
structure with a two way trust to the ship’s domain within the same forest topology, 
allowing access to the ship’s server resources. The embarking unit is responsible for 
providing and maintaining workstations and performing all domain and user accounts 
related activities. The required servers to support this host domain can be provided by the 
ship or augmented by the embarking group. 

e. Seamless Trust between NMCI and IT-21 

This solution has not been implemented and is under analysis. This 
solution is intended to establish a trust across NMCI and IT-21 organizational 
boundaries. This will require a trust between each IT-21 ship (almost 200) to NMCI, 
resulting in intensive personnel management of all system administrators, restrictions and 
strictly enforced levels of access of all administrators. This project is currently under 
evaluation by the PEO’s. 

3. ONE-NET Deployables Mechanisms 

ONE-NET has implemented two technical solutions across the enterprise to 
support ONE-NET users deployed to NMCI and IT-21 environments. These solutions 
include: Two Way Trust between NMCI and ONE-NET, and the ONE-NET deployables 
solution. An overview of each solution is provided below: 
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a. Two Way Trust between NMCI and ONE-NET 

The two-way trust between the ashore networks was described in Section 
2.a in this Chapter. 

b. ONE-NET Deployables to IT-21 

PEO EIS Embarkables solution, also referred to as ONE-NET 
Deployables, allows deployment of both personnel and equipment outside the ONE-NET 
environment while providing commands the ability to integrate into the shipboard 
networks to obtain IT services (ONE-NET does not deploy to an NMCI environment). It 
supports entire commands or individual users with the primary users being the 
AIRWINGs in the Far East. This is the process of interest for this thesis as it is 
implemented for ONE-NET users integrating into IT-21 environments. 

During an Embarkables event when ashore users are deployed to the ashore 
network, IT-21 must successfully and timely perform certain actions to ensure the 
deployed elements have access to critical combat support, and combat service support 
information immediately after deployment beings. 

F. DEPLOYABLES (EMBARKABLES) PROCESSES TO IT-21 

One of the current Embarkables shortcomings is the variation of Embarkables 
processes followed by the various deployers. These variations result from the different 
organizational requirements to deploy, the size of the deploying unit and the home 
network the unit belongs to. This section analyzes the NMCI and ONE-NET 
Embarkables process for embarking units brining their own pre-position servers onboard 
and establishing a trust with the ship’s network. 

1. NMCI Embarkables Process for Large Deployers 

The NMCI Deployables Process consists on the creation of a visitor domain on 
the IT-21 environment and leveraging the automatic transitive trust with the ship’s 
domain for transport services off the ship’s boundary. The deployables domain connects 
to the unclassified LAN on the same Virtual Local Area Network (VLAN) as the ship 
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assets, and the deployables traffic is routed via the WAN router to the shore NOC. This 
WAN connection is shared with other IT-21 traffic including CENTRIXS, secret and SCI 
data as depicted in Figure 5. 



Figure 5. NMCI Connection to Afloat Network (From Smith, 2003) 

The deployables solution was engineered for the enterprise but it is primarily used 
by the large deployers since it requires an Embarkables server suite and IT personnel to 
support the embarking assets throughout the duration of the deployment. A high level 
step-by-step Embarkables process is illustrated in Figure 6 and explained in more detailed 
in following subsection and in Table 2. Pre-deployment step-by-step process for 
NMCI Embarkables 
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NMCI Embarkable Process: 
Step-by-Step 


DA2.4 or Higheris 
installed in deployable 
systems 



CTR submits deployment MAC. Unit IT 
verifies PUK is generated and delivered 
(when applicable) 



Notify CTR of return 
CTR notifies Hel Desk of return 
Stop email redirection 


t 


Operate in Remote Network 
In event of breakdown use spares 
Contacts Help Deskforreplenishment 


Connectto NMCI 
Join Domain 
Run DSA 
Return PUK 
Migrate data to NMCI 




i 


UnitIT verifies user email 
redirection, migrates data to NAS 
Run DSA, Disconnect, Testand get 
underway 


Figure 6. NMCI Embarkables Process: Step-by-Step (From Rivera, Deployables 

STEAG Brief, 2009) 


Pre-Deployment Process: It is the embarking unit’s responsibly to plan for a 
deployment and initiate the Embarkables process by submitting an Embarkables 
Move/Add/Change (MAC) and requesting ODAA approval to connect to the IT-21 
network. Upon completion and approval of a Memorandum of Agreement defining roles 
and responsibilities between the ship and the embarking unit, the Unit IT requests all 
required administrative passwords, a Pack-up-Kit (PUK) with a copy of the gold disk and 
authorized applications, and verifies the availability of an Embarkables PPS suite for 
their use onboard the IT-21 environment. The Embarkables Staff Integration Team 
(ESIT) works with the Unit IT to ensure proper hardware and software configuration and 
functionality of embarking users and workstations. 

Typically, the Embarkables servers suite components consists of three (3) servers 
(Primary Domain Controller (PDC), Backup Domain Controller (BDC), Exchange 
(EX1)), two (2) Direct Access Storage (DAS) devices, and a Network Access Storage/ 
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Network Fiber Attached Storage (NAS/FAS) device, with two (2) continuous 
uninterrupted power supply units that are attached to the IT-21 backbone switches 
(Program Executive Office C4I, 2003). The NAS/FAS device’s function is to support the 
large number of deployable unclassified seats and users associated with the embarking 
unit and to provide the same storage capability as while connected to the ashore network. 

To mirror the IT-21 servers’ configuration, the Embarkables servers are loaded 
with the Common PC Operating System Environment (COMPOSE) load as a POR 
baseline with the latest security patches and anti-virus definitions. The embarking Unit IT 
is provided with all needed administrative rights on the IT-21 network to facilitate 
integration, administer the Embarkables machines, support sustainment and operation 
during deployment, and to accelerate re-integration back to the native network upon 
completion of deployment. 

The core of the NMCI Embarkables mechanism are the Deployables Application 
(DA) and the Deployables Management Tool (DMT) for embark capable seats and users. 
DA is installed on the workstations to perform the background processes for deploying 
computers. DMT performs background communication with the NMCI Domain 
Controllers, SQL and Exchange servers via Remote Procedure Call (RPC) and automates 
the preparation of users and computers by establishing administrative credentials for use 
during deployment and adjusts state of network dependant services only (workstation 
modification is limited to avoid costs associated with reconnecting the workstation to the 
network as users disembark). It suppresses the Enterprise Management System (EMS) 
functionality on the deploying seat by disabling services which broadcast out to NMCI 
servers. It turns off all “noisy” enterprise management applications and prepares seats for 
integration into shipboard Embarkables network. It disables the Information Assurance 
(IA) and EMS agents which remain inactive for the duration of the deployment (Navy 
Marine Corp Intranet, 2005). Disabling HBSS is not currently performed by DMT and it 
remains a manual process. 

The following list of applications and services are disabled on each workstation 
by the DMT in preparation for deployment: 
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• Computer Browser (Proxy server) 

• CPR Loader 

• Enterprise Security Agent 

• Intruder Alert Agent 

• Radia Notify 

• Radia Scheduler 

• Radia MSI Redirector 

DTM enables the following SAV (Symantec antivirus) services on each client: 

• DefWatch 

• Norton Antivirus Client 

Table 2 provides the required actions to be executed (prior to embarkation to the 
IT-21 environment) by the user, the help desk, or by an authorized system administrator 
for Marine units leveraging the ship’s PPS (Burgard, 2011): 
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Action ID 


ACTION 


1 

Host domain is created on IT-21 and registered at the NOC. 

2 

Validate PPS suite connection to the IT-21 environment. 

3 

Exchange, Domain controllers and DNS servers on PPS are configured. 

4 

Validate TWT between ship's domain and Embarkables domain. 

5 

User accounts are created on PPS Primary Domain Controller (PDC) 

6 

User copies PC data into external media or on their home drives for migration 

7 

DMT disables IA and network management agents on workstation 

8 

Email is configured for redirection from the native network to user’s IT-21 email address by the help desk or 
by each user using the DTM tool. 

9 

Windows printing service is integrated with the Ship’s Active Directory 

10 

NMCI objects from existing Organizational unit (OU) structure in AD are moved to a parallel deployed OU 
structure on the NMCI AD structure. 

11 

Workstations from ashore networks with non-COMPOSE image, are connected directly into the IT-21 LAN 
and joined to the domain. Note: Workstations are not reimaged prior to connecting into IT-21 

12 

LAN and Outlook settings on workstations are pointed to the PPS suite. 

13 

IT-21 pushes HBSS agent and HIP to manage HBSS policy during deployment 

14 

Web Browser settings on all workstation are configured to point to the shipboard Proxy Server and allow for 
internet access. 

15 

NMCI Symantec Antivirus clients are redirected to the Symantec antivirus Server on the PPS. 

16 

Command and users home drives are created on the PPS. 

17 

Command data and user Home drive data on NMCI storage devices are migrated to NAS prior to 
embarkation. 

18 

Back up schedules for PPS and NAS/FAS are verified. 

19 

A Pack Up Kit (PUK) is obtained and carried onboard for spares and break fix instructions. 

20 

A consolidated Information Systems (IS) Help Desk is established for break fix issues between the ship’s 
help desk and the unit’s IT staff. 

21 

Additional workstations, networks drops, IP addresses are coordinated with IT-21 network system 
administrator. 


Table 2. Pre-deployment step-by-step process for NMCI Embarkables (From 
Burgard, 2011 and Navy Marine Corps Intranet, 2010) 


The ESIT continues supporting the deploying unit from ashore and throughout the 
duration of the deployment. ESIT ensures the NOC is correctly relaying e-mail to the 
Deployable domain; maintains and develops documentation and deployment plans and 
methods for each type of embarkation model; and provides support to the deployed unit 
as needed via e-mail, phone, or onsite tech assist to resolve critical issues. 
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During Deployment: During an Embarkables event, NMCI provides the 
following services to embarked units outside the NMCI environment as specified in the 
NMCI contract (Navy Marine Corp Intranet, 2005): 

• Reachback 

• Data Migration 

• E-Mail Redirection 

• Troubleshooting for Deployed Seats 

• Logistics for Deployed Seats 

• Training 

The non-NMCI network service provider such as IT-21 provides the following 
services and capabilities (Navy Marine Corp Intranet, 2005): 

• Internet Protocol (IP) based communications support 

• Data aggregation at local (unit LAN) level 

• Information Assurance (IA) 

• Data storage at the deployed location 

• Security 

• System Management 

• Legacy Applications Support 

• Preferred Publication List (PPL) certification support 

• Data Migration/Retention 

• Web Access 

• File and Print Services 

• Directory Services 

• E-mail (Hosting) 

A local administrator password is issued to the Unit IT for each deployment. The 
Unit IT is responsible for maintaining the Embarkables servers and workstations to its 
home network’s baseline, including up-to-date security and administrative policies by 
performing all maintenance and break fix activities on the embarked units including but 
not limited to following list in Table 3. 
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Action ID 

ACTION 

1 

Ensuring antivirus updates are being pulled and GAL synchronization on domain exchange servers 

2 

Ensuring all applicable LAVA patches are applied to all workstations 

3 

Ensuring all machines have the latest anti-virus definitions. 

4 

Maintaining seat(s) operational functionality 

5 

Ordering and managing spares replacements 

6 

Rebuilding any seat(s) as necessary' utilizing the Break Fix tool and process 

7 

Enforce configuration management of embanked systems 

8 

Ensuring all installed infrastructure and equipment is maintained within configuration standards 

9 

Performing Full System Backup of the NAS. 

10 

Providing technical support for embarked assets 


Table 3. During deployment User IT responsibilities (From Navy Marine Corps 

Intranet, 2010) 


In this state, workstations have the networks management agents disabled and can 
no longer connect to NMCI. User accounts remain active throughout the duration of the 
deployment and user e-mail is redirected to the IT-21 address. 

Post-Deployment: Upon completion of the deployment, the process is inverted 
in order to reintegrate into the native network. Post deployment processes are dependent 
on the command policies and regulations to reconnect to the home network. 

The Unit IT must re-baseline the workstations prior to integration back to the 
home network. IT-21’s HBSS is removed for NMCI seats and POR Servers; Retina scans 
on NAS/FAS are performed and discrepancies are remediated; Unit IT must remove any 
installed applications (licensed or unlicensed application) before re-entering to the NMCI 
domain. Due to the complexity of bringing each workstation up its NMCI baseline, 
especially if applications were loaded and proper patching was not performed during 
deployment, some commands opt out to reimage the workstations prior to ashore 
integration. Post-deployment processes and issues are addressed locally by the native 
network staff, and are outside the scope of this thesis. 

2. ONE-NET Embarkables Process for Large Deployers 

The ONE-NET Deployables process was developed to integrate and support users 
using a similar process to the NMCI process currently used by the IT-21 staff and ESIT 
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personnel. ONE-NET most frequent embarking units are the Airwings in Japan. These 
embarking units are integrated into an Embarkables forest and connected to the unclass 
LAN topology as depicted in Figure 7. An AD two-way-trust is manually established 
between the Embarkables forest and the ship’s forest for transport services to the shore 
NOC and to leverage ship resources. ONE-NET Embarkables traffic shares WAN the 
li nk s with the secret and SCI traffic back to the NOC. 



Figure 7. ONE-NET Connection to Afloat Network (From Smith, 2003). 

The current ONE-NET Embarkables process largely mirrors the existing NMCI 
deployable process in order to gain efficiency, commonality and standardize the process, 
hardware and training. Figure 8 illustrates the ONE-NET high level deployables process. 
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Unit IT provides deployment info directly to DTM. DTM 
automatically notify Enterprise Service Desk and PUK is 
generated and delivered by LNSC. 



Unit IT coordinates with Remote Network, Email 
redirection is automatically scheduled, Admin 
Return to ONENET Password from Enterprise Service Desk, 

Seat Automatically re-integrates Disconnect, testand get underway... 

Unit IT Verifies seat re-integration from DTM 
Return PUK to LNSC Personnel 


t 


Stop email redirection 
Disconnect from Remote Network 



& 


✓ 


Operate in Remote Network 
Use PUK in event of breakdown 
ContactLNSCforreplenishment. 


Figure 8. ONE-NET Embarkables Process: Step-by-Step (From Rivera, 
Deployables STEAG Brief, 2009). 


Similarly to NMCI, ONE-NET Deployables is comprised of DMT, hardware 
assets, spares, and documentation which describes the roles, responsibilities and actions 
required to support deploying assets. The DMT design supports NIPRNet and SIPRNet 
environments and requires approval authority by the ODAA. 

Pre-Deployment: The process initiates by the Information Assurance Manager 
(IAM) appointing a Unit IT who is responsible for properly managing the deployment 
process from beginning to end. OCONUS commands coordinate deployment with the 
Local Network Service Center (LNSC) or Theater Network Operations and Security 
Center (TNOSC). 

Users to be deployed are identified and are issued a seat capable of deploying. 
The deployment is then scheduled using the DMT for e-mail redirection and to prepare 
the workstations to a deployable state. DMT places computer objects into a windows 
security group upon deployment date. Members of this security group receive the Internet 
Protocol Security (IPSEC) workstation policy GPO which restricts network access, only 
allowing communication to Domain Controllers (join workstation to domain, Dynamic 
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Host Configuration Protocol ( DHCP)), Tivoli (Scans, Patching), Symantec (Antivirus 
definitions) as well as the DMT Server on the date set for deployment. 

DMT adjusts the state of network dependant services, such as disabling or turning 
off services broadcasting out looking for ONE-NET servers. The list of these services is 
constantly modified based on the ONE-NET baseline updates and includes the following 
services (Space and Naval Warfare Systems Center, 2010): 

• Computer Browser (Proxy server) 

• Tivoli Management Agents including remote control and endpoint 

• Windows Firewall/Internet connection sharing 

• Symantec’s Antivirus Endpoint Protection (SEP) 10.1.9 

• Exchange export fields 

• IPSec policy to restrict access during reintegration 

• Password associated with deployed administrative credentials 

The following steps listed in Table 4 are executed by the user, the help desk or by 
an authorized systems administrators and aided by the LNSC or TNOSC: 
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Action ID 


ACTION 


1 

Host domain is created and IT-21 and registered at the NOC. 

2 

If command embarking with PPS, the server suite is connected to the IT-21 unclass LAN 

3 

An Embarkables forest is created following the ship's naming convention 

4 

A TWT is established between IT-21 and the visiting domain. 

5 

User domain accounts are created on PPS ; including email 

6 

User copies PC data into external media or on their home drives for migration 

7 

DMT disables LA and network management agents on workstation, except HBSS 

8 

Email is configured for redirection from native network to user’s IT-21 email address as bulk by the Unit IT 
desk or each user using the DTM tool. 

9 

Exchange, Domain controllers and DNS server are configured to point to the ship’s servers 

10 

Windows printing service is integrated with the ship’s Active Directory'. 

11 

ONE-NET objects from existing Organizational unit structure in AD are moved to a parallel deployed OU 
structure in AD 

12 

A hidden AD contacts with all existing user information (phone numbers, display name, etc) is redirected 
using the email address as a custom recipient address. 

13 

LAN and Outlook settings on workstations are pointed to the PPS suite. 

14 

Workstations with ONE-NET baseline image are connected directly into the IT-21 LAN and joined to the 
ISNS domain. 

15 

Web Browser settings on all workstation are configured to point to the shipboard Proxy Server and allow for 
internet access. 

16 

Symantec Antivirus clients are redirected to the Symantec antivirus Server on the PPS. 

17 

Command and users home drives are created on the PPS 

18 

Command data and user Home drive data on NMCI storage devices are migrated to PPS NAS prior to 
embarkation. 

19 

Back up schedule for PPS and NAS are verified. 

20 

A Pack Up Kit (PUK) is obtained 

21 

A consolidated Information Systems (IS) Help Desk with the ship's help desk is established for break fix 
issues. 

22 

Additional workstations, networks drops, IP addresses are coordinated with IT-21 network system 
administrator (PEO-EIS, 2010). 


Table 4. Pre-Deployment step-by-step process for ONE-NET Embarkables (From 

Burgard, 2011) 


At this state, deployable computers have limited access to the home network for 
the duration of the deployment but ONE-NET accounts would remain active as users 
were coming back. A local administrator password is issued to the Unit IT for each 
deployment. The Unit IT is responsible for maintaining the Embarkables servers and 
workstations to the ONE-NET baseline and for properly executing the activities required 
during deployment as listed in Table 3. 
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3. Shortcomings for the Existing Embarkables Process 

As DoD forces continue deploying all around the world, the existing NMCI and 
ONE-NET Embarkables mechanisms provide embarked users some of the required IT 
capabilities, but gaps exist, resulting in an impact to the embarked unit’s readiness and 
efficiency. Some of these gaps or additional labor intensive activities are derived from 
process differences. Although the Embarkables process was established to support all 
users at the enterprise, the primary users are large deployers such as Marine Units and 
Airwings. Single users and small groups who do not normally deploy are not familiar 
with Embarkables process; their Unit IT(s) do not receive the proper training and are not 
aware of the Embarkables tools available to facilitate a smooth deployment such as the 
ESIT support and the PPS capabilities (Embarkables Staff Integration Team , 2008). The 
following are some variations of the Embarkables Process for large deployers: 

• ONE-NET and NMCI have different variation of DTM tools and 
capabilities. NMCI tool provides Unit IT less visibility and control to 
manage the deployment vice ONE-NET tool. 

• IT-21 provides PPS for Marines on large platforms but Airwings are 
bringing their own AES and PPS servers. Instructions and configuration 
settings for command provided PPS are provided by the ESIT but due to 
the variation of possible configurations, additional work and 
troubleshooting is required to integrate the PPS into IT-21. 

• Each network has different security requirements enforced by ODAA 
which result different firewall settings. 

• Re-integration to the native network process varies depending on the 
security requirements set for each network and the policies specified by 
the network’s organization. 

• Users or small commands without access to PPS or NAS devices cannot 
leverage these capabilities and therefore are directly connected to the IT- 
21 LAN as a host client. 

In addition to process differences, gaps on services and capabilities received by 
the embarked units vary depending on the network they are coming from, the amount of 
users in the embarked unit and the Embarkables mechanism used. These gaps are 
identified by analyzing what is currently provided by the home networks as described in 
Table 1 and comparing to services and capabilities obtained by the embarked units on IT- 
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21 environments using the Embarkables process. Three user cases are defined and 
analyzed to identify gaps in services received while deployed: 

User Case 1 -Airwings, Marine or any other command user on a host domain 
riding the ship’s network for transport services and for minimal access to ship resources. 
The command is on its own domain connected to the Ship’s LAN as depicted in Figure 5 
and Figure 7 with a two way trust with the ship’s domain. The AES, Pre-Position Servers 
including the NAS devices for data migration are available. DMT is used to prepare 
workstations and disable services previously listed. User e-mail is re-directed to an IT-21 
e-mail by the user, the Unit IT or the help desk. Mechanism used : NMCI Deployables 
process 

User Case 2 - Single or Small group of NIPR users directly connecting to IT-21 
ISNS LAN for all IT services on a small platform. Embarked users bring their home 
network deployable workstations, but ship or command does not provide PPS or NAS 
capabilities. DMT is used to prepare workstations and disable services preciously listed. 
User e-mail is re-directed to an IT-21 e-mail by the user, the Unit IT or the help desk. 
Mechanism used : NMCI Deployables Process 

User Case 3 - NIPR User connecting directly to the IT-21 network for all IT 
services. User is deployed without a deployable workstation or laptop and will require an 
IT-21 provided seat for network access. This user case represents the single or small 
group of users having to embark on an IT-21 environment or those Commands who not 
normally deploy and is not familiar of the process. User ashore e-mail is not redirected to 
the IT-21 e-mail, but can be accessed via Outlook Web Access. Mechanism used: User is 
added to IT-21 topology under Embarkables OU. 

Evaluating the services and capabilities obtained during an Embarkables event by 
each of the three User cases described above, and comparing to User requirement 
identified in Table 1, gaps in capabilities were identified and summarized in Table 5. 
User needs colored in red represent unmet needs during an embarkation. Yellow fields 
represent those needs requiring additional reconfiguration to the network prior to 
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Embarkables integration. Green fields represent the needs that seamlessly provided by the 
host network and/or capabilities provided by using the PPS and NAS. 


NEED ID 

USER NEEDS 

User 

Case 1 

User 

Case 2 

User 

Case 3 

N1 

Cryptographic logon to workstation (cached users) 



_ 


Domain account 



Network access 


Send/Receive Email 


Attach and open email attachments 


Access to Contacts 


Access to Native Network Global Address List 


Ensure workstation protected from cyber attaches and spam 


Shared Calendar 


Accessibility to user data and email files on local hard disk such as .pst files as part of user profile 


Accessibility to user data and email files stored on the user home drive 


Outlook Capabilities (email settings, print styles, email rules and setting, etc) 


POD digital email signature and encryption capability for home network email 


POD digital email signature and encryption capability for host network email 


MS Office and Other local DoD approved apps for seat/user 


Protected data transmissions 


Web access and Cache 


Authentication Services—PKI/CAC 


OS and application patching 


Access to web based applications including certificate-based authentication applications 


Native Home drive to view, edit, crate and delete files depending on use access 


Native Command shared drive to view, edit, crate and delete files depending on use access 


Access to Public Folders 


Local and network data integrity 


Locate and connect to home and share drives 


Seat Local Data storage capacity 


Receive administrative policies and user privileges 


Security policies applied to account 


Application management 


N30 

Air Card and Wireless capability 




N31 

Print/Scan/Fax capabilities 




N32 

Locate and connect to printers 




N33 

Chat and Instant Messaging (IM) 




N34 

Access to collaboration tools (i.e. Defense Connect Online (DCO) 




N35 

Command Document collaboration / Portal (SharePoint) 




N36 

24/7 Help Desk 




N37 

Technical support 




N38 

Capability to create a trouble ticket and check status 




N39 

Training capabilities 




N40 

Tech Refresh 


N41 

HW repair or spares (PUK) 


N42 

Capability to transfer files 



N43 

Messaging—Alerts 




N44 

Secure, available and reliable network connection (99% Service Level Agreement) 




N45 

Backup and Restore Capability 



N46 

MAC (Move, Add, Change) Capability 


N47 

VTC capabilities 


N48 

Access to IT-21 Global Address List 




N49 

Access to IT-21 resources such as applications 




N50 

Ability to store to external media 


N51 

Produce and Manage Audio and Graphic Media 


N52 

Disconnect/Log out 


N53 

Ensure non repudiation 




N54 

Receive all Computer Network Defense policies and mandates (HBSS/DAR/etc) 






Seamless or provided by PPS and NAS 
Provided by the IT-21 environment 
Not available 


Table 5. Embarkables Requirements Deltas 
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While embarked units such as users in Case 1 appear to have few seamless 
capabilities, these are due to the PPS and NAS for the most part. Once workstations are 
added to the ISNS domain, local user profdes and data can only be accessed by system 
administrators, therefore users have no access to their locally stored data once they are 
joined to the domain as their workstation becomes part of the COMPOSE environment. 

E-mail redirection allows users to have all e-mails received on their native 
network e-mail address to be forwarded to their IT-21 mailbox after Microsoft Outlook 
settings have been reconfigured to point to the ship’s exchange servers. E-mail not set for 
redirection can be accessed via web using the proper credentials to authenticate the same 
way it can be accessed from a home network, via web access and with the proper user 
authentication. This requires users to have their CAC capable seat on the IT-21 network 
and proper credentials to authenticate and access their native network to retrieve e-mail. 

Any network storage capability such as home drive and command shared data is 
only available when PPS and NAS are used and data is migrated to these devices prior to 
deployment. Network operation and management activities are supported by the Unit IT 
staff for large deployers bringing an Embarkables server suite or by the ship’s staff for 
small deployers. Users without Unit IT support fully depend on the ship’s staff to 
integrate into IT-21. 

G. CHAPTER SUMMARY 

Existing Embarkables mechanisms have improved the way embarked units 
perform their operations during deployment but still some shortcomings exist. The 
existing NMCI and ONE-NET Embarkables processes share a level of commonality 
especially for connection to IT-21, but the lack of defined and approved enterprise 
Embarkables requirements, inconsistencies in Embarkables processes, and difference in 
network policies lead to variation of these Embarkables capabilities and gaps. 

This chapter identified IT capability gaps faced by users in embarking different 
scenarios. Based on the analysis, it is evident that there is a lack of network 
interoperability between ashore and afloat networks. The use of PPS and NAS provide 
many of the needed capabilities to large deployers, such as Marine units and Airwings, 
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but there no solution available for small units or single users who do not usually deploy, 
or for smaller decks who might need to support small group of ashore users. 

Additionally, NMCI and ONE-NET are constantly evolving and therefore the 
embarkation procedures are always changing, requiring tuning and automation when 
feasible, and identifying new procedures that must be performed to successfully integrate 
the Embarkables assets into IT-21. 

Although the Embarkables processes for Marines and Airwings are implemented 
and are functional, capability gaps exist and impact the services provided to the end user 
and the security status of the workstation during deployment. 
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III. EMBARKABLES ROOT CAUSE ANALYSYS 


A. INTRODUCTION 

From its conception in 2000 to its contract end in 2011, NMCI followed a 
contractor-owned contractor-operated (COCO) model for providing IT services to the 
Navy and Marine Corps. Alternatively, IT-21 and ONE-NET were under a government- 
owned government-operated (GOGO) model, in which the government owns and 
operates all network related activities. Although IT-21 and ONE-NET had a GOGO 
model, both networks were (and currently are) managed by different Program Offices and 
sourced through different funding lines. 

The outcome of these programmatic differences and the uniqueness of 
environments the three networks operate under led to variations in design, capabilities, 
and operational and maintenance strategies across these networks. 

As the DoD strives toward network alignment to maximize productivity and 
efficiency while minimizing cost, the immediate need for ashore units to embark into an 
IT-21 network with no downtime in productivity needs to be addressed in the short term. 
Embarkables mechanism and processes are in place to facilitate user mobility from 
network to network while maintaining adequate level of IT services in a timely manner, 
but these mechanisms have been designed and implemented as “quick fixes” to address 
the loss of IT services experienced by embarking units resulting from nonexistent 
interoperability between networks. Embarking units constantly face integration problems 
with IT-21 environments due to constant modifications on ashore and afloat 
environments and lack of Embarkables process standardization at the enterprise level. 

Although the existing Embarkables mechanisms alleviate the immediate need to 
receive basic IT services during a deployment, they do not address the root cause of the 
network interoperability problem. This lack of interoperability adds labor intensive 
processes, induces risks due to manual intervention and adds costs to the Navy’s mission. 

This chapter identifies and analyzes the contributing factors and potential root 
causes affecting the Embarkables assets when connecting to an alternate network by 
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performing various analyses and implementing systems engineering tools. A Functional 
Decomposition was developed for a network as an ashore system providing common IT 
services (such as NMCI and ONE-NET). A traceability matrix maps system functions to 
customer needs previously identified in Table 1, followed by tracing those system 
functions to system components to identify those system components introducing 
technical and programmatic issues to the Embarkables integration into the afloat network. 

A root cause analysis was performed by developing an Ishikawa cause and effect 
diagram, also known as a “fish bone” diagram, on the areas of most impact. The Ishikawa 
diagram identified contributing causes of the problem in five major categories leading to 
the identification of potential factors causing the overall effect. Identifying and 
understanding the relationships between these sources of variation is a key element to 
develop and implementing corrective courses of action. 

B. FUNCTIONAL DECOMPOSITION AND TRACEABILITY 

The Common Systems Function List (CSFL) v.9.1 by the Assistant Secretary of 
the Navy (ASN) Research, Development and Acquisition (RD&A) Chief Engineer 
provides the basis to identify functions for related C4I and net-centric system functions. 
The CSFL was utilized as the functional framework to develop a functional 
decomposition of a DoD network providing common IT services. The CSFL functional 
framework consists of five Tier 0 functions: 1.0-Combat, 2.0-Sustainment, 3.0-Business, 
4.0-Enterprise Application Support Services and 5.0-Enterprise System Services. 

Tier 0 functions 4.0-Enterprise Application Support Services and 5.0-Enterprise 
System Services cover most IT services provided by an ashore network. Additional 
functions such as 2.0-Sustainment and 3.5-Logistics also apply to the system but are not 
directly connected to the root cause of the Embarkables problem, therefore were not 
included in the functional decomposition. Figure 9 and Figure 10 illustrate Tier 0 and 
Tier 1 of the system functional decomposition for functions 4.0 and 5.0. Further 
decomposition was performed following the CSFL as guidelines down to Tier 5 where 
applicable and the list of system functions is provided in the Appendix. 
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Figure 9. Enterprise Application Support Services Functional Decomposition 



Figure 10. Enterprise System Services Functional Decomposition 


System functions were mapped to User Case 2 needs (customer requirements) in a 
system function-to-customer requirements traceability matrix provided in Table 6. User 
Case 2 was the scenario used for the traceability matrix to represent single or small 
groups of embarking users without PPS and NAS devices. User needs colored in red 
represent unmet needs during an embarkation. Yellow fields represent those needs 
requiring additional reconfiguration to the network prior to Embarkables integration. 
Green fields represent the needs that seamlessly provided to User Case 2 by the host 
network. 
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NEED ID 

USER NEEDS 

SYSTEM FUNCTIONS 

N1 

Cryptographic logon to workstation (cached users) 

4.2.8,5.2 

N2 

Domain account 

5.2,5.4.4.1.8 - 5.4.4.1.13,5.5 

N3 

Network access 

5.2,5.4.4.1.8 - 5.4.4.1.13,5.3.5.5-5.3.5.6, 5.5.18-5.5.19 

N4 

Send/Receive Email 

4.2.4.1,4.8.1, 5.2,5.3.5.5 - 5.3.5.6, 5.3.6.1 - 5.3.6.10, 

5.4.4.1,5.5.58, 5.5.15 

N5 

Attach and open email attachments 

4.3.3,4.8.3 

N6 

Access to Contacts 


N7 

Access to Native Network Global Address List 


N8 

Ensure workstation protected from cyber attaches and spam 

5.3.5.6,5.4.4.1.9.7 

N9 

Shared Calendar 

4.2.2.2,5.4.4.1 

N10 

Accessibility to user data and email files on local hard disk such as .pst files as part of user profile 


Nil 

Accessibility to user data and email files stored on the user home drive 


N12 

Outlook Capabilities (email settings, print styles, email rules and setting, etc) 

4.2.2,4.2.3,4.2.4 

N13 

DOD digital email signature and encryption capability for home network email 


N14 

DOD digital email signature and encryption capability for host network email 

4.2.14, 5.2,5.4.4.1.9.7.1 - 5.4.4.1.9.7.3,5.5.6,5.5.19 

N15 

MS Office and Other local DoD approved apps for seat/user 

4.1,4.2.8,4.3.1,4.3.2,4.3.3,4.3.5,4.4.5,4.7.10,4.8.3,5.2, 

5.7 

N16 

Protected data transmissions 

5.4.4. - 5.4.5 

N17 

Web access and Cache 

4.7.3,5.3.5.6,5.3.9,5.4.4.1,5.4.4.1.8 

N18 

Authentication Services—PKl/CAC 

5.4.4.1.9.7.1,5.5.19 

N19 

OS and application patching 

5.4.4.1.9.7, 5.4.4.1.9.7.6 

N20 

Access to web based applications including certificate-based authentication applications 

4.2.8,4.7.3,5.3.9,5.5.19 

N21 

Native Home drive to view, edit, crate and delete files depending on use access 


N22 

Native Command shared drive to view, edit, crate and delete files depending on use access 


N23 

Access to Public Folders 


N24 

Local and network data integrity 

4.7.11,5.2,5.3.5,5.4.4.1.9.7.4,5.6.1 

N25 

Locate and connect to home and share drives 


N26 

Seat Local Data storage capacity 

4.7,4.8.3,5.2,5.4.2 

N27 

Receive administrative policies and user privileges 

5.4.4.1,5.5.18 

N28 

Security policies applied to account 

5.4.4.1.9.7,5.5.18 

N29 

Application management 

5.3.0 

N30 

Air Card and Wireless capability 


N31 

Print/Scan/Fax capabilities 

4.4.2,5.4.4.1.8,5.4.5.3,5.5.9,5.5.15 

N32 

Locate and connect to printers 

5.2,5.4.5.3,5.5 

N33 

Chat and Instant Messaging (IM) 

4.2.10,4.2.11,5.2,5.4.5.4 

N34 

Access to collaboration tools (i.e. Defense Connect Online (DCO) 

4.2.12,5.3.5,5.5 

N35 

Command Document collaboration / Portal (SharePoint) 

4.7,4.8.3,5.1,5.3.5,5.5.18,5.5.19 

N36 

24/7 Help Desk 

3.5.2.1-3.5.2.2, 

N37 

Technical support 

3.5.2.1-3.5.2.2,5.4.4.1.9.8 

N38 

Capability to create a trouble ticket and check status 

3.5.2.1-3.5.2.2 

N39 

Training capabilities 

3.5.2.3.8 

N40 

Tech Refresh 


N41 

HW repair or spares (PUK) 

3.5.2 

N42 

Capability to transfer files 

5.2,5.3.5, 5.4.5.3, 5.5 

N43 

Messaging—Alerts 

4.2.11,5.4.5,5.5 

N44 

Secure, available and reliable network connection (99% Service Level Agreement) 

5.3.1-5.3.3,5.5 

N45 

Backup and Restore Capability 

5.3.1-5.3.3,5.6.1-5.6.2 

N46 

MAC (Move, Add, Change) Capability 

5.3.1-5.3.4,5.7 

N47 

VTC capabilities 

4.2.13, 5.5 

N48 

Access to IT-21 Global Address List 

5.2,5.3.6,5.4.5.1 

N49 

Access to IT-21 resources such as applications 

4.2.8,4.7.3,5.3.9,5.5.19 

N50 

Ability to store to external media 

4.2.15,4.4.7,4.8.3,5.3.1-5.3.3 

N51 

Produce and Manage Audio and Graphic Media 

4.4.3 

N52 

Disconnect/Log out 

5.2,5.5.9,5.5.15 

N53 

Ensure non repudiation 

5.4.4.1.9.7.3 

N54 

Receive all Computer Network Defense policies and mandates (HBSS/DAR/etc) 

5.4.4.1.9.7, 5.4.4.1.9.7.6 



Seamless or provided by PPS and NAS 
Provided by the IT-21 environment 
Not available 


Table 6. Need-to-Function Mapping 


40 









































































Analyzing the system requirement gaps (in red and yellow) and their respective 
system functions, the most reoccurring functions and those impacting high-priority IT 
services such as e-mail are identified in Table 7. These system functions were mapped to 
system components to identify those components causing or contributing to the 
deficiency of network services provided to embarking units. 


FUNCTION 

Back End 

Architecture 

Network 

Management 

system 

IA 

PC 

image 

4.2 Perform Calculation Services 






4.2.2.2 Shared Calendaring 

X 





4.2.8 Manage Desktop Communication Applications 

X 


X 

X 

4.7 Data Management Services 





|4.7.2 Conduct Data Storage/Retrieval/Updating 

X 




5.3 Provide Network Applications Services 






5.3.0 System functions that provide the capability to access 
and use applications on the network 




X 


5.3.5 Disseminate operational/tactical information 


X 




5.3.6 Exchange electronic mail 

X 





5.3.8 Provide network applications scalability 




X 

5.4 Provide Network Services 






|5.4.4.1.9 Manage network operations 


X 





5.4.4.1.9.3 Perform account management 

X 






5.4.4.1.9.7 Perform network information 
assurance/security management 


X 

X 



5.4.5 Provide Networking Desktop Services 






5.4.5.1 Provide Directory Services 

X 





5.4.5.2 Share Files and Printers 

X 




5.5 Provide Transport Services 






5.5.17 Access Control 

X 


X 



5.5.18 Role / Privilege Management 

X 





5.5.19 User Management 

X 





Table 7. Function to Component Mapping 


The Back-End-Architecture system form is the component which introduces the 
most IT service deficiencies for an embarking system. Network management, IA and 
Workstation image also contribute to the system interoperability between networks as 
illustrated in Table 7. 

The system components were further analyzed to identify root causes resulting 
network interoperability: (1) Network management including IA, (2) Back-End- 
Architecture, and (3) PC image. 
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C. ENTERPRISE NETWORK MANAGEMENT 

As new computer network technologies constantly emerge and mature, DoD 
leverages and further enhances these technologies for communication capabilities with 
the goal of information superiority around the globe. Consequently, networks are 
increasing in size, capabilities, and complexity, requiring active managing and 
monitoring of all network assets to promptly and efficiently diagnose any problems, 
mitigate any possible risk, prevent and remediate network vulnerabilities, identify 
possible security threats, and secure the networks’ integrity, confidentiality and 
availability. 

Adversaries aggressively seek to penetrate and damage DoD networks with cyber¬ 
attacks and continuous malicious activities which threaten tactical information and 
overall DoD missions. Securing DoD networks is essential to attain and maintain data’s 
integrity, information sharing, situational awareness and mission effectiveness. Directives 
and regulations for the monitoring, detecting, reporting and remediating of any network 
vulnerabilities or threats to computer networks are enforced at every level of the 
Computer Network Defense (CND) structure as illustrated in Figure 11. Security policies 
must be implemented at every layer of the CND. All these layers, from the desktop level 
to the DoD Global Integration Grid, are constant targets of physical and cyber attacks and 
require the implementation of security mandates to secure the network at every level such 
as: IAVA compliance at the desktop, LAN and WAN layers; HBSS at the desktop and 
DON GIG, Data at rest at the desktop level; and IP Blocking at the LAN, WAN and GIG 
layers to name a few. 
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Figure 11. Computer Network Defense (From Department of the Navy Chief 

Information Officer, 2009) 


Managing, securing and maintaining Navy networks requires advanced enterprise 
management solutions consisting of physical structure, tools, policies and processes 
strictly enforced. Network management solutions comprise software and hardware 
components as well as processes operating cohesively to secure the network by 
performing a variety of functions: server and application monitoring, operating system 
and application patching, security posture enforcement and screening, software 
distribution, change management, trouble ticketing, asset management and inventory 
collection of hardware and software. 

IT-21, NMCI and ONE-NET developed customized network management 
solutions based on their unique needs and operational constraints. ONE-NET Enterprise 
Management System (EMS) core is an International Business Machines (IBM) Tivoli 
framework product which uses one single agent active at the network hosts to provide all 
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EMS functionalities (Purhagan, 2010). IT-21 uses Microsoft Systems Center 
Configuration Manager (SCCM) for patch management, software distribution and 
inventory. IT-21 is currently deploying an enterprise patch management solution for all 
PMW-160 POR system utilizing a Microsoft Windows Server Update Services (WSUS). 
NMCI uses Radia for patch management and software distribution; NetMeeting is used 
for remote control access as NMCI help desk is contractually obligated to obtain user 
permission to remotely access the workstation during an incident ticket resolution 
process. NMCI recently migrated from BCM Remedy to Service Manager (SM) 7.0 for 
Incident ticket creation and monitoring, including self service ticketing. 

Table 8 summarizes the functionalities provided by the enterprise management 
systems and the tools utilized by each network. 


Functionality 

IT-21 

NMCI 

ONE-NET 

Patch Management 

SCCM 2007 

Radia 

IBM Tivoli Configuration 
Manager (TCM) 

Software Distribution 

SCCM 2007 

Radia 

IBM Tivoli (TCM) 

Remote Control 

SCCM 2007 

NetMeeting Remote 
Desktop Connect 

IBM Tivoli Remote Control 
(RC) 

Incident Ticketing 

BCM Remedy 

SM 7.0 

BCM Remedy 

Inventory 

SCCM 2007 

Radia 

IBM Tivoli (TCM) 

Monitoring 

SCCM 2007 

Data not available 

IBM Tivoli Monitoring 

Network monitoring 

WhatsUpGold 2.5 

Cisco Works 

IBM Tivoli Net View 

Event Management 

SCCM 2007 

Data not available 

IBM Tivoli Enterprise 
Console (TEC) 

Image Deployment 

SCCM 2007 

SM 7.0 

IBM Tivoli (TCM) 

Computer Defense Network 

McAfee’s Hercules 4.5 

Radia 

IBM Tivoli 


Table 8. Network Management Functions and Tools (After Podwoski, 2011; Navy 
Marine Corps Intranet, 2009; and Purhagan, 2010) 


Securing Navy networks has become the primary function for the network 
management system by enforcing Information Assurance (IA) DoD directives to maintain 
compliance on the security posture across the enterprise. The DoD Directive (DODD) 
8500.01E and the Chairman of the Joint Chief of Staff Instruction 6510.01F provide 
direction and guidance on the implementation of security requirements, controls, 
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protection mechanisms and standards for all DoD owned or controlled information 
systems that receive, process, store, display or transmit DoD information, regardless of 
mission assurance category, classification or sensitivity (Department of Defense, 2007). 
This is accomplished via an effective network management tool and process as part of the 
enterprise network management solution. 

Navy and Marine workstations stay compliant while connected to their home 
network by constantly receiving security updates and OS and application patches. 
Embarked workstations connecting to an alternate network experience loss of 
connectivity to their native network disabling the ability to be centrally managed, thereby 
impacting the functionally of the following key subsystems to maintain the IA 
compliance: Data at Rest (DAR), HBSS, Network Access Control, Secure Configuration 
Compliance Validation Initiative/Secure Configuration Remediation Initiative 
(SCCVI/SCRI), Digital signature matching, Cryptographic Log-On (CLO) 
Authentication, User Based Enforcement (UBE), Firewall, GPOs, and Cached Login 
Credentials. 

The following subsections identify network interoperability deficiencies for a 
seamless integration of Embarkables workstations into the afloat network affecting patch 
management; DAR; and HBSS policy enforcement, monitoring and reporting. 

1. Patch Management 

Operating system and application software vulnerabilities of one or multiple 
assets introduce security risks to the entire network to which the assets are connected. To 
correct such vulnerabilities, software fixes called ‘patches’ are pushed to the network 
when vulnerabilities are identified. Patch management is a key method to enforce 
network security by identifying, monitoring, mitigating and remediating software 
vulnerabilities. Timely identification of un-patched software and a prompt and effective 
enterprise remediation action is essential to secure Navy networks and their data. 

This subsection identifies potential factors causing the patching deficiencies by 
developing an Ishikawa diagram to determine any technical and programmatic elements 
resulting in the inability for ashore workstations to seamlessly receive software patches 
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from the IT-21 network during a deployment. These potential factors were identified by 
reviewing IT-21, NMCI and ONE-NET documentation and interviewing subject matter 
experts on the following: 

• The patch distribution and management processes for the IT-21 network 
and the Embarkables patching process to identify gaps in these methods 
and the driving factors for those variations. 

• The network management tools utilized to perfonn all patching and 
software distribution functions by each network to identify discontinuity 
in meeting network patching requirements and tool incompatibility, 
resulting in the inability to leverage the IT-21 network management tools 
while connected to its topology. 

• The operational environment each network operates under and how 
elements related to the environment were decision drives for the tool 
selection and the employed patching process. 

• The operating commands and personnel managing these tools and 
processes to detennine procedures’ ownership, and manpower limitations 
such as lack of cross-trained personnel to identify how personnel affect the 
overall patching of Embarkables. 

The contributing causes for these factors were grouped under four major 
categories: Equipment, Environment, Processes and People in the Ishikawa diagram. 
Potential contributing components for each category were identified by implementing the 
5 Why’s technique where appropriate to further identify root causes and any relationships 
between these causes directly or indirectly impacting the overall effect: the inability for 
Embarkables to receive patches when connected to the IT-21 ISNS LAN. 

a. Network Management Tools 

Software patch distribution and management requires a customized 
patching process and deployment tool to release patches and hot-fixes across to the 
enterprise. Network management and patching tool features include: manipulating 
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security configuration settings, deploying standard software packages, scanning OS and 
applications, monitoring and reporting, and maintaining policy compliance by taking an 
active role in vulnerability remediation. IT-21, NMCI and ONE-NET have fielded 
customized network management processes and use different management tools to scan 
and patch their client and server infrastructures. 

IT-21: IT-21 supports COMPOSE versions 2.x to 4.x on shipboard ISNS 
LANs and the patching process varies based on the COMPOSE baseline. Most ships are 
on COMPOSE v3.0 or higher versions and use SCCM, a Microsoft product for managing 
windows based computer systems and provides remote client and server control, patch 
and software management, and operating system deployment (Program Manager Warfare 
160, 2011). First introduced with COMPOSE v3.0, the SCCM product did not support a 
Tiered environment (such as NMCI and ONE-NET) but this was not a requirement for 
IT-21. 

NMCI: The new HP Client Automation Enterprise (CAE) system (using 
Radia at the client) is used as the software and patch manager for NMCI assets. CAE 
automates scheduled night connections to deliver software and Radia Daily Connect for 
startup and login scripts at boot up. 

ONE-NET: ONE-NET’s Enterprise Management System uses the IBM 
Tivoli line of products including the IBM Tivoli Configuration Manager for patch and 
software distribution. It uses Windows Patch Management System (WPMS) to push OS, 
application patches and software to maintain the Information Assurance Vulnerability 
Management (IAVM) compliance (Purhagan, 2010). 

Table 9 summarizes the different tools used for patch management and software 
distribution by the three networks resulting in tool incompatibility across network 
environments. 
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Network 

Network 
management tool 

Vendor 

IT-21 

SCCM 

Microsoft 

NMCI 

Radia 

Hewlett-Packard 

ONE-NET 

Tivoli 

IBM 


Table 9. Network Management Tools (After Purhagan, 2010 and (Program 

Manager Warfare 160, 2011) 

b. Patching Process 

Each network has an effective patch management process for its 
workstations to receive all required patches while connected to their native network to 
maintain compliance and for delivering software to the enterprise. 

IT-21: Deployed ships are unable to use terrestrial-based systems for 
communications and the only method of communication to ashore facilities is via satellite 
li nk s. This limitation introduces a challenge to patch management for IT-21 and 
Embarkables assets due to the limited bandwidth available during deployment as monthly 
and critical patch pulls result in high bandwidth requirements on the already saturated 
SATCOM links. 

DISA manages a notification service which provides information on 
trusted and authenticated Microsoft and other software patches to be disseminated to 
DoD networks. IT-21 identifies applicable patches to each COMPOSE environment and 
makes those accessible at the POR approved patch repositories: the Naval Networks and 
Sailor websites. 

Shipboard administrators manually initiate the download from the patch 
repositories and determine which patches apply to their platform configuration. Due to 
the size of some of these patches, ship to shore synchronization and pull of patches are 
scheduled during non-critical fleet operations. Patch pulls often congest the SATCOM 
li nk s and fail due to size of patch and the latency of the connection. After patches have 
been downloaded and are available on the ship’s LAN, pushing patches to all the assets 
must be carefully planned and security considerations addressed. The security patch 
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deployment instructions recommend scaling down the number of simultaneous 
workstations installations to prevent any degradation of network performance due to the 
heavy traffic load. 

IT-21 patching process using the WSUS incorporates a 3rd party tool 
called EminentWare to patch non-Microsoft Windows-based applications on all 
COMPOSE 3.x or higher environments and other applicable PMW-160 systems 
including coalition networks as CENTRIXS-M. Together, these tools automate the 

delivery and implementation of software patches to the fleet, providing more control as to 
when patches are pulled to ensure no impact on ship’s operations (Program Manager 
Warfare 160, 2011). 

WSUS provides a hands-off approach to downloading and managing 
software updates. The service automatically synchronizes with upstream WSUS servers 
to remain up to date with the most recently approved updates for Microsoft applications 
as well as Windows-based non-Microsoft applications that have been configured to 
communicate with WSUS. Once synchronization is complete, WSUS manages 
installations for all updates and provides reporting capability for Microsoft updates 
(Department of the Navy PMW160, 2011). Non-Microsoft patches are managed and 
reported through InfoPath forms. Information on new updates and update approvals are 
delivered to downstream servers, and update installation and client requirements data is 
transmitted to the upstream server during scheduled synchronizations. Any updates are 
created on the master servers and replicate throughout the organization in a downstream 
fashion: software support activities’ master servers to the NOCs to the ships. 

While IT-21 is standardizing the patch management solution across the IT- 
21 environment using the WSUS, this new patching solution has not been tested for 
Embarkables workstations. The use of the WSUS would eliminate the need for the Unit 
IT to initiate the patching process by downloading appropriate patches from the NMCI 
Home port website or Naval Networks websites. Patching Embarkables seats remains an 
isolated process to the ship’s patch management process. 


49 



NMCI Embarkables process: NMCI patches are packaged, tested and 
posted on the websites for download. For large deployers, the Unit IT is responsible to 
download patches to a source patch directory to be accessible to all workstations and 
servers requiring patching. For small groups or single users without Unit IT, it is the user 
and the ship’s responsibly to maintain compliance. NMCI developed the Deployables 
Unmanaged Patch (U-Patch) Utility solution to aid the deployed units validate and update 
their Client Data Seat’s IAV security posture, and to distribute patches and security 
updates to NMCI embarked assets. 

The U-Patch Utility is part of the deployable workstation baseline. A 
server or workstation is assigned as the patch repository to keep all required network 
patches for the embarking units. During deployment, the source directory for patches 
must be configured on all workstations and it must be accessible to the logged user with 
the proper read pennissions. U-Patch utility runs in silent mode on each asset, each time a 
user logs on the utility checks for new patches to download and process. The frequency 
the seat checks for new patches can also be configured. Critical patches can be forced to 
run after the user has logged on to the seat. For workstations without U-Patch or without 
access to the source directory, manual patching must be performed by the user or IT staff 
to maintain compliance. 

ONE-NET Embarkables process: It is the Unit IT’s and ship staffs 
responsibility to maintain all seats and PPS servers IAVA compliant by delivering 
applicable ONE-NET patches which are available for download from the PMW-160 
Naval Network Web-page. ONE-NET facilitates seat patching with the implementation 
of the Deployable Workstation Management (DWM) Patch Distro tool. The DWM tool 
performs discovery of ONE-NET workstations in the Embarkables or ship domain 
requiring patching, and an executable file (dwm.exe) perfonns the patching (Purhagan, 
2010 ). 


c. Operating Environment 

During a deployment or when terrestrial connectivity is unavailable, Navy 
vessels depend on military satellite communication systems augmented by commercial 
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satellite systems to enhance the capability, reliably and performance of radio frequency 
connectivity back to shore. This operational environment introduces bandwidth 
constraints and connection latency issues furthered discussed Section D. The unique 
circumstances the ships encounter during deployment influence the afloat patching 
process. The intermittent SATCOM connection to the shore limits the software patch 
download and the internal patch distribution to its assets. Most patches are large in size 
and the link’s latency and intermittent connection result in patch download failures. 
Additional environment limitations and their impact on the Embarkables patching 
deficiency is illustrated in Figure 12. 

d. People 

Although the three networks are owned by NETWARCOM, they are 
managed by different program offices and sourced through different funding lines. PMW 
205 manages NMCI and ONE-NET while PMW 160 manages the IT-21 network. During 
deployment, it is the Embarkables Unit IT’s responsibility to ensure that the hundreds of 
embarking assets (servers and workstations) are properly patched throughout the duration 
of the deployment. This is a time consuming task to perform, it must be manually 
initiated and any workstation not properly receiving patches must be physically visited by 
the Unit IT. 

The ship’s staff is unavailable to support the Embarkables patching 
process as their primary responsibility is to support the ship’s users and communications. 
Additionally, the ship’s staff uses a different patching process and patching tool 
compared to the Embarkables tool; this unfamiliarity contributes to the limited support 
they can provide to the patching of Embarkables assets. 

The identified causes for each category were grouped under their 
respective categories to construct the Ishikawa diagram depicted in Figure 12. 
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BW constraints 


HBSS must be reconfigured 
Patch pull failuro 



Different AD structure 


Different patches apply 

Different Operational 
Environment 


Patching process variations 

Different Tools 
Non-Standard process 
Continuous upgrades, hard 
to keep updating documentation 

Ship needs control of patch distribution 
Limited time window 
Limited automation within ship 
Old versions SMS still operational 

Current tool SMS not BW throttling 


Labor intensive 

Manual process (partial) 

Downloaded from various sites 
Different patches for diff networks 
Patch download impractical 


Different Patches apply 

Time consuming 

Repetitive process on ship 
Process not followed 

Ownership of 
Patching responsibility 

Difficulty obtaining patchos 

Variation of processes 



Tired vs. non-Tired environments 

Security patches add 
heavy load to network 


Patch distribution 
Limitation 


Embarkablos adds 100's of 
Assets and consume resources 


> Link drops 

Patch too large U - DIL connections 

DIL connections U -Ship movement/impact 
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/ blockage 

/ Limited communication 
links(SATCOM) 

Antenna Handover 
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Different management tool 

Different Network 
management structure 
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Different operational rqts 

Tirod vs. non-Tired environments 
Different AD structure 


IT(s) not cross-trained 
for diff. tools 
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Don’t know 
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Ship's cannot 
Easily support 
external commands 

Understaffed 
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Don’t follow the process 
Time consuming process 


Manpower limitations 


Users don't know 
procoss 


No connection to host 
patch servers 

Different dosktop imago 
different patches apply 
No connection to native patch servers . 

Not connected to native network- 

Disabled by DTM — 

Embarkables PCs cannot _1 

Access management tool 

Different AD structure 
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Different network architectures 



Embarkables cannot 
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Different tools 
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Different Vendors 
No interface solution 
Between tools 
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Different operational environments 
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Non-framework products 

Management Tool interoperability 
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and constraints 
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Different AD Structures 
Framework vs. 
non-framework Tool option 
Tool requirements 


Figure 12. Ishikawa Diagram for Patch Management 
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As illustrated in the Ishikawa diagram, the environment category introduces the 
operational environment variation impacting the Embarkables ability to receive patches 
during deployment. This category identified possible factors resulting in the inability to 
receive Embarkables patches during deployment, such as the large size of the patches, the 
bandwidth limitation and intermittent SATCOM links. It also identified the contributing 
factors impeding the utilization of shipboard patching tools, such as the difference in 
tools currently used to patch the network assets, and the interoperability between these 
tools. 

The Process category identifies the variations in patching processes implemented 
by the IT-21 network and the ashore networks, the impractical and inconsistent process to 
download applicable patches for Embarkables seats, how the difference in management 
tools drive variations in patching process, and the fact that different networks require 
different patches to be applied to their assets. 

Under the People category, the variation in process and the different patching 
tools contribute to the inability to leverage the ship’s IT personnel to patch Embarkables 
seats during deployment as they are unfamiliar with the ashore process and tools. 

The Equipment category identifies the difference in patching tools and possible 
root causes of that variation, including cost factor and the network requirements driving 
the selection of different tools by each program office to be implemented on their 
network. 

To summarize, the following sub-causes have the most influence on the four 
major categories: (1) Differences in patch management tools: Embarkables units cannot 
be centrally managed by the IT-21 network due to different management tools used 
which are not compatible, resulting in the need for an Embarkables utility; (2) The 
patching process requires a manual download of afloat patches during deployment and is 
one of the causes of the inability to patch seats: the size of patches is too big to download 
via SATCOM; low bandwidth, high latency and intermittent connection causes patch 
downloads to fail; Unit IT must manually search for patches that apply to the 
Embarkables seats which is time consuming and could result in the wrong patch 
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attempting to be applied; (3) Different patches apply: IT-21 image and applications 
require different patches than the NMCI and ONE-NET images. 

The different AD structures derive from the different environments the three 
networks operate under. Management tool interoperability is due to the difference in tools 
utilized which were selected based on requirements, cost, and constraints. Furthennore, 
unclear requirements contributed to the difference in tool selection as each network 
worked independently on the patch management process around its constraints and to 
meet is specific operational needs. 

2. Advanced Client Security Policies - Data at Rest (DAR) 

Malicious or non-malicious network vulnerabilities that are introduced into the 
network contribute to the constant loss of sensitive information, placing the anned forces 
at risk. Some of these vulnerabilities result from negligence or failure to protect both data 
in transit and data at rest on DON networks. On July 3, 2007, the DoD Chief Information 
Officer (CIO) issued a memorandum establishing a DoD policy to protect sensitive 
unclassified information on mobile computing devices and removable media (Space and 
Naval Warfare Systems Center, 2010). 

DAR refers to all data stored on hard drives, thumb drives, Compact Discs/Digital 
Versatile Discs (CD/DVD), floppy diskettes, and similar storage media. It excludes data 
that is traversing a network or temporarily residing in computer memory to be read or 
updated (Metz, 2006). DAR is composed of several integrated elements to provide a 
complete data protection platform to the enterprise: (1) Hard Disk Encryption, (2) 
Removable Storage Encryption (RSE), and (3) Advanced Authentication Pre-Boot 
Authentication (PBA). 

• Hard Disk Encryption protects against unauthorized reading or copying of 
data off a protected hard drive. It encrypts a workstation’s hard drive when 
it is powered off and auto-decrypts it when the workstation boots up. 

• RSE encrypts data copied to a removable storage device, CD/DVD, it 
protects all data transferred off a DAR-protected workstations and it is 
operable with non-DAR workstations. 
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• PBA allows registered users to boot workstations following user 

authentication using a common access card (CAC) or alternative logon 
token. Only registered CAC certificates loaded in workstation memory 
would be authorized. 


DAR uses the user’s Public Key Infrastructure (PKI) encryption certificate within 
the DoD CAC to protect the full volume encryption key. Multiple users on the 
workstation or device are able to use their individual DoD smart cards for boot 
authentication. Figure 13 illustrates the DAR concept. 



Figure 13. DAR for Hard Disk and Removable Storage (From Space and Naval 

Warfare Systems Center, 2009) 

a. DAR Solutions for DON Networks 

DoD approved eleven DAR solutions, including Mobile Armor and 
GuardianEdge (GE) encryption solutions. GE was selected for NMCI and ONE-NET, 
and Mobile Armor for the other Navy networks. Networks require waivers to employ a 
different encryption solution by other than GE and Mobile Armor. DON selection of 
alternatives was influenced by the Embarkables requirements to administer workstation 
during deployments. Selecting a different DAR encryption solution for ashore and afloat 
networks allows for local administrators to have certain privileges to continue managing 
workstations when connecting to IT-21 during deployments. 

Table 10 summarizes the DAR solutions (or future implementation) by 

each network. 
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Network 

Encryption Software 

Version 

Vendor 

IT-21 

Mobile Armor (future) 

na 

Mobile Armor (future) 

NMCI 

GuardianEdge Products 

9.5.x 

Symantec (formerly GE) 

ONE-NET 

GuardianEdge Products 

9.1.5 

Symantec (formerly GE) 


Table 10. DAR Software Solution Summary Table 


NMCI has deployed all three elements of DAR using GE Encryption 
Anywhere (GE EA) software, and the GE Removable Storage (GERS) utility. It is also 
enforcing PBA where a workstation boots after cached user has been authenticated. 

ONE-NET’s GE EA Platfonn is based on a modular design that contains 
three functional components: GE Data Protection Framework, the GE Manager (DAR 
Manager) and the Client modules GE Hard Disk Encryption, GERS and GE EA. The 
implemented ONE-NET DAR solution includes the Hard Disk Encryption and the 
Removable Storage Encryption elements; PBA has not been deployed on ONE-NET. 

IT-21 DAR solution is under development and has not fielded any data at 
rest encryption capabilities to date. 

b. DAR and Embarkables 

DoD Directive on protecting data at rest applies to all DON systems 
regardless of the network they are connecting to or their deployment status. NMCI and 
ONE-NET assets deploying into IT-21 must comply with the CIO directive by employing 
DAR even during deployment state. 

NMCI and ONE-NET DAR solutions consisting of GE products continue 
working in a disconnected or deployed state. Workstations however, do require regular 
connectivity to DAR servers for GPO updates, recovery key check-in (for back-up 
recovery functions), status information stored on server, and to rebuild a workstation 
whose hard drive is inaccessible. This connection back to the DAR services is 
unavailable for workstations connecting to the afloat network. 

Workstations’ hard disks are encrypted (with the exception of the 
bootstrap files necessary to boot the system) by GE when a workstation is shut down and 
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its data is protected while residing on the hard drive. Data is then auto-decrypted by GE 
products at boot up and accessible to the user. A GE Hard Disk encryption feature is to 
lock a protected workstation that has failed to check with the DAR Manager (located at 
the shore) within a specified number of days. If this feature is implemented, the hard disk 
would be locked and would require a client administrator to unlock. This feature is 
currently not implemented by any network. 

DAR Embarkables users can encrypt files on removable storage devices 
and those files can be decrypted by IT-21 or any other workstation with different DAR 
solution or with no DAR solution at all. This is accomplished by copying the GE 
Technologies Access Utility into the removable storage devices, to be used by decrypting 
workstations. This allows data mobility during a deployment. 

While DAR solution works in isolation, it enforces stringent local security 
workstation policies which hamper the Embarkables process. Embarkables require 
escalated privileges to workstations for the Unit IT to reconfigure the network 
management agents, network configuration, data migration functions, reimage and 
rebuild seats, unlock GE Hard Disk-protected workstations and unregister GE users. This 
ability to administer a seat cannot be locked by DAR or be lowered down to a user access 
in order for the Embarking Unit IT to be able to successfully connect into the IT-21 LAN. 

To mitigate this issue, Unit IT(s) are provided with client administrator 
password to enable them to perform the administrative functions required during 
deployment. Preset Client Administrators are allowed to access the workstation by 
authenticating (using a username and password) to GEHD at the logon prompt and to 
Windows at the Windows logon prompt and are not required to authenticate with a DoD 
CAC. These accounts are inserted into the client software installation package prior to 
deployment and cannot be modified during a deployment. These accounts ensure the Unit 
IT can unregister GE users and decrypt a partition or partitions regardless of GPO 
processing (Space and Naval Warfare Systems Center, 2009). 

When System restore tools are used to repair a corrupt boot section on the 
workstation’s hard drive, a common tool is the IBM Rescue and Recover application. 
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This application requires the Master Boot Record (MBR) to be properly configured for 
the application to function and it replaces it with its own settings. GEHD relies on the 
MBR and modifying it results in system problems. GEHD incompatibly with some 
system restore tools which modify the MDR results in unbootable systems making it very 
difficult to retrieve the data on the hard disk. 

Although the status quo permits encrypted data mobility between 
networks, workstations cannot be centrally managed; there is no reporting to the DAR 
manager; there is no implementation of GPO updates; and Unit IT(s) require a client 
administrator account and procedure to integrate the workstation into the network and to 
unsure functionally. 

Current afloat DAR solutions, although using the same products, are not 
compatible with each other or with other networks. To perform integration with other 
networks, an alternate product or GuardianEdge 9.3 or higher is required in both 
environments. NMCI is currently on 9.5.x and ONE-Net on 9.1.5 (Space and Naval 
Warfare Systems Center, 2009). 

3. Host Based Security System HBSS 

On October 9, 2007, the Joint Task Force for Global Network Operations (JTF- 
GNO) released Communications Tasking Order (CTO) 07-12 mandating the deployment 
of the Host Based Security System (HBSS) on all combatant command, service and 
agency secure and non-secure networks within DoD (LandWarNet, 2008). 

The HBSS baseline is a COTS-based application for the detection, monitoring, 
and countering against known cyber-threats to DoD Enterprise. It is attached to each host 
(server, desktop, and laptop) in DoD, managed by local administrators and configured to 
address known exploit traffic using an Intrusion Prevention System (IPS) and host 
firewall. DISA provides guidance regarding the deployment and operations of HBSS, 
defines baselines and configuration settings consistent with DoD requirements and 
guidance, and revises/concurs with all deviations from HBSS architecture necessary for 
operational requirements. DISA provides HBSS software (i.e. patches and hot fixes) 
available for download to the DoD community (Defense Information Systems Agency, 
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2010). Each DoD network is responsible for developing an HBSS solution to meet all 
DISA mandates and adhere to policies, define network specific configurations, and test 
solutions and updates prior to deployment. 



Figure 14. HBSS concept (From Defense Information Systems Agency, 2011) 

HBSS is currently at baseline v4.5, Maintenance Release 2.0 (MR2). It is 
composed of multiple software applications, which together provide system management, 
policy enforcement and reporting capabilities consisting of the following McAfee 
products (Defense Information Systems Agency, 2010): 

• ePolicy Orchestrator (ePO) server- responsible for collecting and 
displaying events, controlling policies, and managing the product 
modules at the clients via the McAfee agent. 

• Host Intrusion Prevention System (HIPS) - protect against kn own 
and unknown malicious activity including, worms, Trojan horses, 
buffer overflow attacks, malformed commands, critical system file 
modifications, unauthorized access to system resources and 
privilege escalation. 

• Policy Auditor (PA) is responsible for ensuring compliance with 
information security mandates such as Federal Information 
Security Management Act of 2002 (FISMA). 

• The Assets Baseline Module - addresses system baseline 
configurations and changes to respond to Information Operations 
Condition (INFOCON) changes necessary during times of 
heightened security threats to the system. 

• The Rogue System Detector (RSD) - provides real-time detection 
of new hosts attaching to the network. 

• Device Control Module/Data Foss Prevention - The DCM 
component address the use of USB devices on DoD Networks. 
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The HBSS McAfee Agent (HBSSMA) on clients provides the basic 
communication mechanism between workstations and ePO server. It is used by the ePO 
server to enforce policies, reporting, product deployment, detection of possible rogue 
systems connecting to the network, and management of all HBSS modules at the clients. 
The HBSS architecture overview is depicted in Figure 15. 


H8SS 



Figure 15. HBSS Architecture Overview (From Defense Information Systems 

Agency, 2009) 

c. HBSS solution on DON networks 

IT-21, NMCI and ONE-NET have deployed DISA’s HBSS architecture and 
polices, and constantly update HBSS baseline versions to ensure compliance with CTO 
07-12. IT-21 is currently deploying HBSS 3.0. NMCI has upgraded to baseline HBSS 
4.5 MR2 while ONE-NET is currently deploying the same version at TNOSCs. 


Network 

HBSS 

Vendor 

IT-21 

HBSS 3.0 (deploying) 

McAfee 

NMCI 

HBSS 4.5 MR2 

McAfee 

ONE-NET 

HBSS 4.5 MR2 

McAfee 


Table 11. HBSS Baselines on Navy networks 
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Table 11 summarizes the current HBSS baselines on the three DON networks. At 
present, there are different HBSS baselines fielded at the operational environment 
resulting in a miss-match of agents on clients and servers when connecting across 
networks. DISA has released an expiration notification for HBSS 3.0 by February 29, 
2012 to all entities to upgrade to current HBSS baseline 4.5 MR2 in order to continue 
obtaining maintenance support. Such mandates force navy networks to deploy the latest 
versions and achieve baseline consistency across networks, but some networks are falling 
behind with the upgrades. 

d. HBSS on Embarkables 

NMCI and ONE-NET HBSS suite encounters interoperability issues while 
attempting to connect to IT-21 HBSS suite during an embarkation event. This 
interoperability goes beyond the version difference between the networks. This 
subsection explores and identifies the HBSS components and configuration 
inconsistencies causing Embarkables’ problems. 

HBSSMA connection to ePO server: Embarkables workstations loaded 
with McAfee agent v4.5 and v4.0 are unable to communicate with the ship’s ePO server 
currently running on HBSS v3.0 due to: (1) ePO directory paths on workstations point to 
the ePO server of native network, therefore it would fail to establish a required secure 
communication with ship’s ePO server; (2) a mismatch of certification key pair and ports 
used to encrypt/decrypt communication traffic between the ePO server and clients (HBSS 
v3.0 communicates via port 80, HBSS v4.5 communicates via port 443); (3) a mismatch 
of IP addresses and ports configuration on the B2 firewall when a embarked client 
attempts to connect to its native ePO server; (4) mismatch of IP addresses and ports 
configuration on the ePO server’s firewall (Hoang, 2011). 

Host Intrusion Prevention System problems: HIPS uses the ePO 
framework for delivering and enforcing HBSS policies at the enterprise. One of HIPS 
features is the host based firewall which acts as a filter between the workstation and the 
network to which it is connected. The host firewall is configured with policies for 
inbound and outbound traffic for network resources such as exchange, web server, and 
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domain controller. It also defines the type of traffic allowed, applications, IP addresses 
and address ranges specific to the native network. During a deployment, the embarking 
workstation’s firewall is configured to allow traffic from its native network’s information 
such as application ports, protocols, and IP addresses. When connecting to the IT-21 
environment, the firewall might not identify IT-21 network information and block traffic 
between the workstation and the network servers. 

HIPS policies affect Embarkables printing capabilities. Limited physical 
infrastructure and LAN drops onboard ships generate the need to share printers directly 
connected to a workstation. NMCI and ONE-NET HIPS policies do not allow the sharing 
of non-networked devices adversely impacting the printing services while deployed. 

Another HIPS feature is the capability of application blocking which 
monitors applications being used by the workstation and either allows or blocks them. 
This feature is currently not being enforced by ONE-NET. 

Host based IPS enforces a rigid access control and prevents unauthorized 
access, privilege escalation, joining workstations to domains, system file modifications, 
and changing workstation names. This restricts or completely disables the ability for the 
Unit IT to modify workstation configurations and obstruct the workstation integration of 
embarked units into the IT-21 environment using the current Embarkables mechanisms 
described in Chapter II. 

Deficiencies in vulnerability scan results from PA. The PA tool enables 
the execution and scan for compliance of benchmarks such as the Federal Desktop Core 
Configuration or benchmarks defined with the release of IAVM notices. It also scans 
HBSS clients’ configuration settings, compares to the previously obtained baselines and 
reports agent-based vulnerabilities, service misconfiguration, and policy violations. 
Embarked workstations and ship ePO server might have a variation of benchmarks, 
IAVM notices and configurations, resulting in false-positives of a policy violation 
reported by the PA. 

Rogue System Detection: RSD sensors detect unknown systems such as 
workstations, servers, and printers connected to the network and lack the HBSSMA. It 
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sends a message to the ePO server to check in its database if the identified device has the 
agent installed or not. If the unidentified device does not have the HBSSMA agent, then 
it’s considered a rogue system and an alert is created. The system can be blocked/updated 
with the current security policy. IT-21 RSD sensors would detect an Embarkables system 
as both run on different HBSS versions and would then report to the ePO server. The ePO 
server, also on a different version, would categorize the Embarkables unit as a rogue 
system and block or update it. 

Embarkables work-around process: As the DoD community strives for 
increasing information security across all networks, HBSS implementation of policies 
and regulations is an additional component impeding workstation mobility across 
networks. HBSS client configuration and management is unique to each network and is 
not interoperable with other networks for the various reasons previously described. To 
solve this problem and allow NMCI and ONE-NET assets to integrate into IT-21, 
Embarkables implemented a bottom-up approach by developing a process-based solution 
to allow workstations to integrate into the afloat network during a deployment. This 
work-around ensures compliance of embarked servers and workstations while connected 
to IT-21 but adds extra steps, actions and possible failures for a successful embarkation. 

The process requires removal and installation of HBSS by each network. 
NMCI and ONE-NET staffs remove any instance of HBSS into the servers and 
workstations configurations prior to connecting into IT-21. This allows for installation of 
the ship’s HBSS baseline on all connecting assets. Embarked assets then connect and 
report thru the ship’s ePO during the duration of the deployment. Upon completion of the 
deployment, the IT-21 HBSS baseline is removed from all assets and the NMCI and 
ONE-NET HBSS baselines are re-installed prior to reintegration to the native network. 
This labor intensive process allows support for all HBSS fielded baselines, but adds more 
labor and difficulties to the embarking units. 

Although the current process ensures compliance with the CTO 07-12 
mandate, this does not resolve the root cause of the problem. HBSS baselines are 
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networks specific and are not required to be interoperable with other DON networks, 
resulting in the emergent requirement to develop quick fixes to support the Navy’s 
mission. 

D. NETWORK BACK-END ARCHITECTURES 

NNE’s vision for a rapid and seamless integration of Navy and Marine Corps 
assets across networks by achieving common enterprise architecture faces the challenge 
of current divergent network infrastructures and operational environments. Key technical 
aspects and architectural decisions for all three networks were driven by operational 
environments and executed and managed by different program offices across the Navy. 
Such architectural decisions influenced the design of different network architectures, 
variations in system administration and network management services across the 
networks. 

Leveraging the cause-and-effect diagram illustrated in Figure 12, this section 
identifies those operational environment factors and architectural design elements 
resulting in Embarkables connection problems. 

1. Communication links 

The most significant operational environment disparity between the ashore and 
the afloat networks is the wired vs. wireless connections to the NOC. Wired networks 
offer superior performance and reliability over Disconnected Intermittent Limited (DIL) 
satellite communication (SATCOM) connections as bandwidth is limited and li nk s 
constantly drop. This section analyzes how the Navy SATCOM architecture influenced 
the afloat IT-21 architecture into what is today and how it is a major key element in the 
way Embarkables connect to the IT-21 environment. 

By 2010, SATCOM bandwidth requirements during peacetime increased 400 
percent and wartime requirements increased by 500 percent over 1995 requirements 
(Federation of American Scientists, 2011). These li nk s enable the transmission of tactical 
and administrative data within the battle group or to the shore. 

SATCOM capabilities and requirements vary per platfonn and mission. Navy 
vessels are provisioned with multiple SATCOM li nk s and Antennas supporting line of 
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sight to communicate with other ships at a close distance. While in port, Navy vessels 
connect to the NOCs via a terrestrial line using the BLII Piers system where the system 
exists at the pier risers, or remain on its SATCOM connections. The Piers connection 
provides Fast-Ethernet (100 Mbps) speed transport services to the NOC and will increase 
its capacity to Gigabit-Ethernet (1 Gbps) speed commencing in FY13. Figure 16 depicts 
the IT-21 SATCOM and terrestrial connections. 



Figure 16. IT-21 Interfaces (From Smith, 2003) 


During a deployment, only SATCOM links are accessible to transmit tactical, 
strategic and operational traffic back to the shore. SATCOM li nk s are subject to constant 
environmental effects (jamming, atmospheric factors, interference, blockage, hand-over, 
etc.) and become disconnected and intermittent when signals expand, fade, or become 
limited. 

Current SATCOM requirements exceed the available throughput capacity. 
Bandwidth limitation and the intermittent connection of SATCOM links degrades off- 
hull network performance; limits any system replication, synchronization, and reporting 
of network heath and security posture back to the shore; impacts network management 
requirements; disconnects any AD trusts outside the ship’s boundaries; and limits or 
completely impedes access to certain required applications and tools. 

NMCI and ONE-NET are wired networks connecting to the NOC(s) via terrestrial 
lines (mostly fiber), providing secure and reliable network connection with redundant 
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links that can be quickly employed to support net-centric services. In extreme occasions, 
these links get disrupted by environmental factors, but both networks have been able to 
maintain 99% network availability (1.68 hours downtime per week). 

Wired li nk s provide reliable, high throughput connections while SATCOM li nk s 
experience severe bandwidth limitations and network perfonnance degradation due to the 
intennittent connection to the shore. These operational capabilities and constraints were 
the primary influencers of what the current back end architectures are today and will 
continue influencing future architectural decisions. These facts were the main drivers for 
the current AD architectures and the way afloat and ashore networks receive directory 
services and how they are managed and sustained. 

1. Directory Services - Active Directory structure 

Department of Defense enforcement of authentication and authorization of users 
and assets is implemented by the network AD architecture and group policies. It provides 
centralized control and management of network resources with a single point of 
administration and full user access to network resources with a single sign-on using a 
password or smart card. AD is a central location for network administration, and is 
responsible for authenticating and authorizing all users and computers within a network. 
It administers servers, clients, peripherals and users and it serves as the focal point of the 
network as illustrated in Figure 17. 
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Figure 17. Active Directory on a Windows Server Network (From Microsoft 

Technet, 2011) 


Logical topology: Windows AD organizes the networks and its objects into an 
organizational hierarchy of forest, trees, domains, organizational units (OU’s), trust 
relations, and sites as illustrated in Figure 18. Forest models represent the logical 
structure of the network; the physical part of the network is represented by sites. Sites and 
forests are independent of each other, but multiple domains may appear in a single site, 
and multiple sites may appear in a single domain. 
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Figure 18. Logical Structure in AD (From Washburn, 2011) 


A forest is a collection of one or more Windows domain trees that do not form a 
contiguous Domain Name Services namespace with no automatic information sharing or 
trusts established across forests. A domain tree is a set of AD domains that share a 
common namespace and are connected by an automatic transitive two-way trust. All trees 
in a given forest trust each other according to transitive hierarchical Kerberos trust 
relationships, therefore network resources can be shared between the domain trees. An 
AD domain defines an administrative boundary for a collection of objects that are 
relevant to a specific group of users on a network; each domain has a security policy that 
extends to all security accounts within the domain. All domains in a forest have an 
automatic transitive two-way trust established with all other domains in the forest. 
Domains are created for geographical and/or organizational structure. An OU is used to 
group objects (i.e. users, printers) into a logical hierarchy that best suits the needs of the 
organization. 

Administrative Control is delegated over the objects within an OU by assigning 
specific permissions to users and groups (DXNET Training, 2009). 

Physical topology: A site within AD represents the physical topology of the 

network. It usually refers to a group of computers and servers connected by high-speed 
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communications li nk s. Within each site, replication of directory data between DCs is 
automatic. Replication between sites is less frequent and it can be controlled by systems 
administrators to optimize bandwidth utilization and network performance. 

This AD structure allows users to move across domains or trees and be 
automatically authenticated to access network services such as e-mail, contacts, GAL, 
and network drives. 

1. Ashore Networks AD structure - Single Forest Topology 

NMCI implemented the Windows AD (v2.0) single forest/multiple tree model for 
its Navy network (the Marine network is its own forest) consisting of six domains and 
implemented common naming conventions and standards as defined in the AD User 
Object Attributes Specification released by the DoD CIO in 2005. 

The Navy forest contains separate trees and domains each with their own 
namespace. The NMCI’s DON top domain (NADS.NAVY.MIL) is an empty AD forest 
root domain whose primary purpose to provide namespace definition and support forest¬ 
wide administrative tasks. The two child domains are for West Coast and East Coast 
objects. NADSUSWE.NADS.NAVY.MIL is the West Coast domain for all USN West 
objects and NADSUSEA.NADS.NAVY.MILs the East Coast domain for all USN East 
objects; these are the primary logon domains for all NMCI users. The other domains 
support particular communities of interest not falling directly under DoN and are 
therefore outside the scope of this thesis. The unclassified NMCI forest model is depicted 
in Figure 19. 



Figure 19. Unclassified NMCI Navy forest model (From Navy Marine Corps 

Intranet, 2010). 
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ONE-NET AD infrastructure consists of a single forest with two domains in a 
parent child relationship as shown in Figure 20. The parent domain 
OCONUS.NAVY.(SMIL).MIL is the forest root domain and the child domain is called 
DS.OCONUS.NAVY(.SMIL).MIL; this is the primary logon domain for all ONE-NET 
users. ONE-NET’s structure was designed to mirror the NMCI AD structure. Therefore, 
NMCI AD is the focus of analysis with the assumption that the same concept applies to 
ONE-NET (Space and Naval Warfare Systems Center, 2011). 



Figure 20. ONE-NET forest model (From Space and Naval Warfare Systems Center, 

2011) 

The NMCI model is a full mesh of shortcut trust relationships between all the 
domains to increase efficiencies. Shortcut trusts improve the authentication process and 
user logon times between domains or forests as depicted in Figure 21 (Navy Marine 
Corps Intranet, 2010). Two-way-trust relationship between forests was implemented 
between USN and USMC enclaves. External trusts are also established with ONE-NET 
as previously discussed in Chapter II. These TWT between networks allow for the 
access of host network resources while maintaining the network management capacity by 
the native network, including scanning for vulnerabilities and patching. 
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Figure 21. NMCI Navy Fully Mesh Shortcut Trust Model (From Navy Marine Corps 

Intranet, 2010). 

Within domains, NMCI created a multilevel hierarchy of top level OU’s holding 
multiple lower level OUs in a tier structure. The granularity of the each OU structure is 
based on the technical requirements or local administrative policies. 

The NMCI AD enterprise structure includes a Deployable Seats OU to support 
workstations on deployment. As part of the Pre-Deployment process, NMCI objects from 
the existing OU structure in AD are moved to the Deployable Seats OU. The OU 
structure for deployable seats exists at the root of each child domain and is created to 
simplify the management of the security groups and mail-enabled contacts for e-mail 
forwarding purposes. Upon completion of the deployment, objects in the Deployable 
Seats OU are moved back to their original OU location and e-mail redirection disabled. 

The rest of the root level OUs contain exchange, file and print servers; database 
server objects; backup and restore servers; provide security and messaging services; 
GPO’s and distribution groups; contact’s information; DHCP, Windows Internet Name 
Service (WINS) servers and Operational servers, groups, and service accounts. 

Authentication and Authorization: Access Control and Role/Privilege 
Management, system functions 5.5.17 and 5.5.18 identified in Table 7 are executed by 
AD running on the site domain controller. It authenticates and authorizes users, groups, 
and computers to access objects on the network. 
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Upon connecting to the domain, a workstation’s identity requires verification by 
the Local Security Authority (LSA) on the domain controller, and definition of the 
computer’s security context, including the workstation’s capability and access to network 
resources. These rights and pennissions for a computer, user, or group are determined by 
Access Control Lists (ACLs) and contain security identifiers for a computer, user, or 
group managed by Active Directory. Other NMCI’s authorization mechanisms at the 
enterprise include: privileges, IP restrictions, Server-Specific Permissions, Forest/Domain 
Modes and Functional Levels, W2K8 Domain Level Enhancements (Authentication 
mechanism assurance) (Navy Marine Corps Intranet, 2010). 

NMCI and ONE-NET have implemented the smart card single sign-on (SSO) 
using credentials stored in Active Directory. SSO uses credentials collected during an 
interactive domain logon to allow the user to authenticate to a network one time and, 
thereafter, to have access to all authorized network resources without additional 
authentication (Microsoft Technet, 2009). 

AD authenticates logon using Kerberos Key Distribution Center service and 
Kerberos authentication protocol as default. Authentication is performed by the DC 
located at the LNSC for ONE-NET authentication and at AD sites for NMCI. An NMCI 
AD Site meets the following criteria: (1) All NOC, Sever Farms, or micro server farm 
locations where domain controllers reside are defined as an AD site; and (2) Base/air 
station IP subnets not housing or located with DCs are assigned to the AD site of the 
designated SF. Several other authentication protocols are available in the NMCI 
Enterprise: Basic Authentication, Digest Authentication, Forms-Based Authentication, 
New Technology Local Area Network Manager (NTLM) Version 2, Kerberos Version 5, 
X.509 Certificate, and Internet Protocol Security. There is no default authentication 
protocol identified by NMCI, but Kerberos Version 5 was listed as the preferred 
mechanism (Navy Marine Corps Intranet, 2010). ONE-NET uses CAC for front-end 
authentication, and uses Kerberos, Version 5 as the default back-end authentication 
mechanism. 

The Local Security Authority is responsible for all interactive user authentication 

and authorization services on a local computer. Each AD object is protected by access 
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control entries that identify which users or groups can access that object and defines what 
level of access is allowed. NMCI and ONE-NET AD include root-level OUs at each 
domain for Access Control Authentication to hold and manage workstations and printers. 

2. Afloat Networks AD Structure - Multiple Forest Topology 

IT-21 implemented a multiple forest structure where each ship is its own AD 
forest due to the bandwidth limitations and problems with continuity of communications 
between ships and shore. Each ship is entrusted to maintain its AD schema and to 
maintain compliance with the guidance provided by the PEO. This guidance on AD 
naming standards and schema was designed to mirror the NMCI naming standards as 
closely as possible. 

A multiple-forest topology provides messaging service and data isolation, 
including Exchange, which is a requirement for the IT-21 SATCOM environment due to 
the intermittent connections. It establishes strict boundaries between ships’ forests and 
therefore provides a more secure environment than a single forest topology. The IT-21 
AD forest model is illustrated in Figure 22. 



Figure 22. Example IT-21 AD forest model including a Embarkables forests objects 
(From Net-Centric Geospatial-Intelligence Discovery Services, 2002) 
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AD namespace includes the hull number such as 
HULLNUMBER.NAVY.(SMIL).MIL for the ISNS domain (other domains compose the 
IT-21 environments such as SubLAN and SCI). Within the domain, a hierarchical OU 
structure holds all domain objects (Net-Centric Geospatial-Intelligence Discovery 
Services, 2002). 

Authentication: IT-21 has not implemented the smart card logon and it provides 
domain user ID and password authentication capability via workstations to control end- 
user access to network domain resources. The user logon name must be unique across the 
entire Navy and USMC enterprise. Users’ logon interactions are managed by a secure 
process called Winlogon. The LSA receives the user name and password from Winlogon 
and determines whether the logon process is to be authenticated on the local computer or 
across the network as a domain account and the Kerberos authentication package on the 
domain controller validates the user. IT-21 users do not use CAC logon but utilize CAC 
credentials to access PKI enabled websites such as Defense Connect Online (DCO). 

3. Directory Services and Embarkables. 

AD architecture design was primarily driven by the operational environment and 
requirements for each network, where deployed ships’ communications must be able to 
function in isolation due to the low WAN throughput intermittent satellite links 
connecting to the shore. User and workstation mobility across these two different 
architecture structures cause loss or degradation of the following services and 
capabilities: 

Authentication- NMCI and ONE-NET domain authentication is not available for 
Embarkables during a deployment because the DCs reside at the LNSC and there is no 
AD trust between shore DCs and ship DCs. Therefore, an IT-21 domain account must be 
created for users and workstations and must be added to an IT-21 forest. The PPS suite 
includes two domain controllers (for redundancy) to support directory services provided 
to the Embarking units, including user logon processes, user authentication, and client 
security policies. The IT-21 domain controllers perform authentication for embarked 


74 



users without PPS. The AD structure at the ship’s root domain includes an Embarkables 
OU to add users and client accounts for embarking personnel without PPS. 

Outlook services - Users with e-mail redirection to their IT-21 e-mail account 
cannot access the NMCI or ONE-NET global address books, contacts or calendar 
sharing. There is no access to other IT-21 GALs. Internally to IT-21, other ship address 
books are not accessible and address book sharing must be coordinated and obtained via 
shore. 

Embarking units cannot encrypt or sign outgoing e-mail during deployment 
because their CAC e-mail certificate does not match the IT-21 e-mail account being used. 

Security - Workstation security posture is lost over time while workstations are 
not connected to their native network, automated patching management is disabled and 
security policies are not updated to maintain compliance. Unit IT or ship’s staff needs to 
ensure that workstations receive security patches. 

Users and workstations lose role based capabilities, drive mappings and any other 
settings on a GPO appropriate to the workstation and logged on user, as the group policy 
client on the machine won’t be able to access and pull any refresh settings. 

Printing - Printing capabilities to network printers are available through the TWT 
with the ship’s forest. Some limitations do exist to Embarkables assets due to the HIPS 
policies implanted not allowing access to locally shared printers, widely used on the IT- 
21 environment due to the LAN drop limitations. 

Desktop - AD locks down desktops using Group Policies for NMCI, ONE-NET 
and IT-21. Software installation, configuration and updates for Embarkables units must 
be manual loads, as the software distribution agents are disabled during deployment and 
no other software or patch distribution methods are allowed. Non-baseline software 
requires approval and security compliance prior to installation. 

AD provides all mailbox information, GAL services, and other recipient-related 
information, therefore the divergent AD structures on the ashore and the afloat networks 
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make it practically impossible to move across network without major reconfiguration at 
the front and back end of the network (Microsoft Technet, 2005). 

E. CLIENT IMAGE 

IT-21, NMCI and ONE-NET implemented standardized COTS and GOTS 
software bundles, referred to as workstation images, to deliver directory services and 
applications to network clients. A workstation image is a copy of the entire state of the 
system stored in some non-violate form, allowing the image to be restored exactly in the 
same state after a system shut down. Every workstation requires a unique identity within 
each network. The naming convention is unique for each network and enclave and to 
distinguish between desktops and portable workstations. These naming conventions allow 
scripts to accurately target certain users and devices. 

Each network workstation image software bundle consists of seven possible 
software/application categories: (1) core software; (2) security and information assurance 
software; (3) business management applications; (4) media players and file viewer; (5) 
enterprise software management; (6) collaborative tools; and (7) above core applications. 

Core software includes the operating system, web browser and Microsoft software 
framework. Security and information assurance software include DAR products, 
Antivirus, HBSS agents and the latest security upgrades. Business management 
applications consist of Microsoft Office products. Media player and file viewer software 
include: Adobe file viewers, Apple’s QuickTime Player, and Microsoft Media Player. 
Enterprise software management includes SCCM, Tivoli, Radia. Collaborative tools 
include chat, conferencing, and messaging tools such as NetMeeting and Mako chat 
client. Above baseline applications are many but some examples are: Microsoft Project 
and Visio, Adobe Professional, AutoCad, Naval Aviation Logistics Command 
Management Information System (NALCOMIS) and IBM’s MAXIMO which are 
applications for certain commands or user groups but not part of the image baseline. 

IT-21 client core build is the COMPOSE versions 2.0.3, 3.0.0, 3.0.1, 3.5.0 to 4.0.0 
supporting WIN XP Service Pack 3 (SP 3) and Windows 7 SP1. The NMCI Core Build is 
the complete set of core applications for a particular platfonn and OS. NMCI currently 
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supports WIN XP SP3 and WIN7 SP1 (Hewlett-Packard Development Company, 2011). 
The ONE-NET standardized desktop configuration is called the Workstation Baseline 
Software Configuration (WBSC) and the current version is 118, which is based on WIN 
XP SP3. 

The three networks operate on Microsoft Windows platforms WIN XP SP3 and 
WIN 7 SP1 operating systems. Upon release of an new image for NMCI and ONE-NET 
and to validate compatibility with the fielded image due to the continuous updates, the 
IT-21 tests that image on it’s COMPOSE environment to ensure functionally. 

Software and applications in most categories are tied to network resources or vary 
in software product resulting in software and image incompatibility: (1) IA software and 
enterprise management client agents pointing to specific servers for security updates to 
maintain the image compliance such as DAR and HBSS; (2) security template settings on 
workstations based on DISA policies to ensure compliance and maintain network security 
posture vary for each network; (3) variation of Antivirus solutions, IT-21 on Symantec 
Antivirus vlO (SAV 10), NMCI on Symantec Endpoint Protection vll (SEP 11), and 
ONE-NET on McAfee; (4) above baseline applications pointing to servers such as 
MAXIMO and NALCOMIS which is a critical logistics application to log plane and 
flight infonnation; (5) baseline applications pointing to a server (Internet Explorer 
pointing to different proxy server); and (6) floating licensing software pointing to a 
license manger on the network, such AutoCAD used by the Naval Facilities Command 
reaching out to the FlexLM server located at the ONE-NET’s TNOSC in Japan. 

PMW-160 is currently utilizing virtualization technology to build multi-image 
workstations with NMCI, ONE-NET and ISNS (COMPOSE 4.0) loaded to seamlessly 
connect and operate on all three networks. Workstations would then seamlessly connect 
and be centrally managed and maintained on the network they are connecting to. 

F. CHAPTER SUMMARY 

This chapter explored the factors contributing to the Embarkables inability to 
seamlessly connect into a visitor network and obtain IT services without configuration 
requirements at the desktop or network level. By identifying the functionally loss or 
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degradation during a deployment, and mapping those functions to system components, it 
is identified that network management and the back end architecture are the primary 
causes for Embarkables integration problems. 

Patch management deficiencies and functionality issues with the security related 
solutions are directly caused by the variation of management tool and products, and 
processes used to monitor, manage and sustain the network. A deep analysis was 
performed on patch management to identify the root causes for inability of Embarkables 
to receive patches while connected to IT-21. The Ishikawa diagram identified four major 
categories which can be applied to most interoperability issues between the ashore to 
afloat networks: (1) Equipment (Management tool), (2) Environment (Architecture), (3) 
Process and (4) People. The decentralized network management IT-21 model; the 
variation and incompatibility of management tools; the different desktop images 
requiring different patches specifically packaged to be deployed by their corresponding 
patching tools; and the manual process to download patches via SATCOM resulting in 
high failure rate are the primary causes for patching problems during deployments. The 
AD structures between afloat and ashore networks is significantly different. Single AD 
forest vs. Multiple AD forests with no trust to any other forest maintains each ship in 
isolation. Although it is required for IT-21 to be self-sustained while at sea, this isolation 
prevents any data sharing, replication, and collaboration with other IT-21 ships or ashore. 

Current networks are not flexible or adaptable; they were designed to optimize 
performance for each unique environment but were not designed to integrate with other 
networks while optimizing the overall performance of the system of systems. 
Consequently, the PEOs develop and continue improving bottom-up solutions for net- 
centric communications to enable IT services to ashore users while deployed on an IT-21 
environment. These processes and initiatives are interim solutions to afloat and ashore 
network interoperability problems but do not fix the root cause of the problem. 
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IV. RECOMMENDATIONS 


A. INTRODUCTION 

This chapter presents high level recommendations for the existing Embarkables 
process to facilitate integration into the IT-21 environment for services, and consequently 
minimize the embarking user’s downtime. Additional recommendations based on 
successful implementation of IT solutions by the private sector to support mobile and 
remote users are explored in this chapter as viable alternatives for the Navy’s mobile IT 
services requirements. 

B. IMPROVING CURRENT EMBARKABLES SOLUTIONS 

The operational environment of Navy ships requires the network’s ability to 
achieve and sustain self-sufficiency while in a deployment status when SATCOM 
connectivity is lost. While SATCOM li nk s constantly increase in capacity and reliability, 
the demand for bandwidth exceeds the throughput SATCOM links can supply. Exploring 
solutions to alleviate and improve the Embarkables’ integration into the afloat network 
must keep this operational limitation into consideration and should focus on keeping 
SATCOM requirements to the minimum while providing Embarking units the IT services 
required to complete their mission during a deployment. 

1. Ashore Solutions to be Tested against the Embarkables Process 

Although ONE-NET and IT-21 develop networks solutions, naming standards and 
architecture decisions to mirror NMCI as much as possible, there is no interoperability 
requirement for any network. In more recent years, Navy networks have leveraged each 
other’s IT solutions when feasible, as part of the network realignment efforts: ONE- 
NET’s DAR design was based on NMCI’s solution, AD IT-21 and ONE-NET leverage 
the NMCI naming standards and guidance, and NMCI and ONE-NET HBSS solutions 
are same product line and similar policies have been implemented. 

Despite this collaboration among Navy networks and similarities in some 
solutions, there is no fonnal process to validate functionality of solutions across 
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networks. New solutions are tested against their own network and fielded to the 
enterprise without an Embarkables’ evaluation on technical and/or programmatic risks. 
There is no requirement to test new solutions against the Embarkables integration 
process, or to evaluate the impact of the new solution on workstation’s performance 
during deployment. Solutions are fielded to the enterprise without an Embarkables’ 
validation test. As a result, integration issues are identified in real time during a 
deployment, requiring immediate technical support and reverse engineering to indentify 
the root cause of the problem to resolve the issue and integrate the seats into IT-21. 

Incorporating the Embarkables team into the development and testing of any 
enterprise solution would facilitate the early detection of interoperability problems due to 
technology gaps, processes or implementation of security rules and policies. The 
Embarkables team should be engaged with the engineering team to modify the technical 
aspects of the design, or work with the proper authority for policy waivers or 
modifications to prevent integration problems. 

Testing solutions in the IT-21 network prior to fielding would identify most issues 
in a lab environment when there is no impact to the user. Adding interoperability 
verification as part of the test and evaluation process for every solution would identify 
any interoperability problems in a timely manner prior to fielding to the operational 
environment. 

IT-21 is currently piloting the WSUS patch management process. This process 
eliminates the manual selection and download of patches for the COMPOSE environment 
and could be leveraged for the patching of Embarkables seats and saving man-hours. 
While it’s in its pilot phases, there is no requirement to test for Embarkables seats; 
therefore no testing has been perfonned. 

2. Leverage Existing DoD Solutions for Mobile Networks 

NMCI deployed the DSTB solution to support mobile Navy and Marine units on 
remote locations while providing bandwidth optimization over high-latency and unstable 
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WAN circuits. DSTB provides VPN over IPSEC encrypted traffic over multiple external 
networks and delivers “office-like” connectivity to mobile users (Navy Marine Corps 
Intranet, 2011) 

DSTB is a small footprint on the host network, requires one power outlet, one 
public IP address, and WAN and LAN connections. It consists of: one outer router which 
connects to the inbound circuit; one inner router supporting 48 connections; one VPN 
Device; one WAN Accelerator which improves bandwidth performance up to 60%; and 
an uninterruptible power supply for non-permanent installations in a durable case 
(Wolff, 2008). Enhancing the DSTB with a server fann to include file, print and e-mail 
services would allow ashore assets to operate onboard ship with little or no integration. 
The DSTB solution has been deployed by NMCI for pennanent or semi permanent 
deployments, and to support exercises and administrate deployments for 90 days or less. 
For each instance, an accreditation package is submitted, reviewed and approved by the 
ODAA to validate that the system is meeting all security and accreditation policies and 
requirements. 

DSTB provides the transport capability for the network by connecting to NMCI 
via a secure VPN. This connection requires continuous access to a SATCOM link to 
maintain the VPN tunnel and traffic flow in and out of the ship for e-mail, Internet 
access, application access, or any other required service. The ship’s limited bandwidth 
links cannot support this persistent VPN connection for the Embarkables traffic flow to 
the shore. Some of the required IT services must be provided within the ship to minimize 
bandwidth requirements over SATCOM. The PPS suite, currently used by the Airwings 
and some Marine units, provides the data storage capacity, exchange and domain 
controllers needed to provide basic services to the embarking unit. 

Using the PPS with NAS and the enhanced DSTB, users can maintain their native 
network e-mail and GAL, digital e-mail signature capability, CLO, home drives; assure 
access to command shared data, and be assured that the distribution of enterprise services 
and IA security requirements will be maintained during the deployment. The PPS and 
DSTB server fann allow the embarking units to be self-sufficient during SATCOM 
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downtime since network resources remain within the skin of the ship and the DSTB 
allows reaching out to the NMCI environment when SATCOM is available. 

Deployment missions often require direct collaboration across other embarked 
commands and access to ship resources. This requires the creation of a TWT between the 
DSTB and the ship’s domain; it would allow the use of ship’s resources such as printing, 
proxy services, and connection to ship hosted applications such as NALCOMIS for 
aviation logistic information. 

The DSTB solution is currently not used on the IT-21 environment. The primary 
concerns for implementing the DSTB to support Embarkables are the bandwidth 
requirements and the initial fielding cost. The author developed a four year cost estimate 
profile for the acquisition and maintenance of one DSTB System utilizing known initial 
hardware cost, fielding and yearly maintenance costs (Weatherspoon, 2010). Inflation 
data rates and normalized cost estimates to Then-Year dollars (TY$) were used to 
represent the actual cost that can be expected the year the dollars will be expended as 
illustrated in Figure 23. 
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Figure 23. DSTB Four Year Cost Estimate 


This cost profile is based on a DSTB life cycle sample of four years with initial 
acquisition in FY12 ($127,538); assuming 6 month deployments; two deployments on 
even years and one deployment on odd years starting in FY12; one time technical support 
per deployment ($13,000); monthly IAVA support throughout the year ($303 per month); 
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and utilizing the DoD Inflation rates provided by the Office of the Secretary of Defense 
Program Analysis and Evaluation. This cost does not include system accreditation cost, 
or any cost incurred on the ship network services such as bandwidth utilization. Total life 
cycle cost in FY12 dollars is: $228,621. 

A comparison between the total cost to field and operate a DSTB system, and cost 
to associated with the man-hours required to integrate the same amount of Embarkables 
assets during a four year period demonstrate substantial savings to the Navy: a common 
deployment consists of a Commander Air Group with 50 seats and a Commander Carrier 
Strike Group with 800 seats per deployment, totaling 850 users. On average, the Unit IT 
spends 45 minutes per seat (Weatherspoon, 2010). Per deployment, it takes the Unit IT an 
average of 635 hours per deployment. Considering a 4 year period (assuming DSTB 
refresh on the 5th year), and assuming six deployments during the 4 year period, the total 
man-hour savings are approximately 3,800 hours, not including the time to create an 
Embarkables domain, user accounts, redirection of e-mail, and reintegration back into its 
native network which very often requires the reimagining of the workstations. 

In addition to cost associated with using DSTB on the afloat environment, there 
are other technical considerations that would need to be further analyzed and tested: data 
storage requirements, shipboard bandwidth impact, data store synchronization 
requirements, exchange synchronization requirements, operational deployments 
procedures, DSTB technical upgrades, firewall security requirements, and solution 
performance metrics (Rivera, Streamlined Embarkables, 2010). 

Additional considerations are the AD latency tolerance and VPN performance 
over SATCOM. The maximum latency for a reliable IPSEC VPN tunnel between the 
DSTB and NMCI is 600ms Round Trip Time (RTT). Exceeding this maximum latency 
will result in failed connection between DSTB and the ashore network. Typical RTT for 
cross-country or trans-oceanic land-based WAN li nk s are normally in the range of 100 to 
200ms, yet a satellite link is 500ms RTT. Factoring in other normal delays from network 
sources could increase this latency beyond the 600ms for the IPSEC tunnel resulting in 
constant loss of VPN connection (Kruse, 1995). As the Navy operates in areas of the 
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world where bandwidth is extremely scarce and expensive, DSTB bandwidth 
requirements, cost, impact on ship communications and it associated benefits and risks 
need an in-depth study and evaluation. 

3. Enterprise Services for Seamless User Experience 

In the new cyber era ruled by the concept to provide services from a cloud, why 
not utilize the cloud to service military forces deployed anywhere in the world? 

Exchanging e-mail messages has evolved to a fast, reliable, real time 
communication method among physically dispersed users and across networks, 
increasing organizational productivity and profitability. The DoD has become dependent 
on e-mail for communication and information sharing at different security levels, 
enclaves and across military branches. 

Standardizing into a single common Navy e-mail would facilitate the ability to 
seamlessly exchange electronic messages and transition between environments during 
deployment and from anywhere in the world. Achieving a single e-mail model will 
require reengineering the network, fixing the back end architecture considering the 
current constraints, or will require deploying an Off-The-Shelf (COTS) plug in solution. 
While these alternatives represent programmatic and technical challenges, it is essential 
that a system engineering approach is implemented at every phase of the life cycle of the 
system in order to design, build, deploy and maintain the right product at the right cost. 

This section provides an overview of some industry and commercial cloud-based 
solutions that could be used as the basis for a new Navy e-mail service model. 

a. Cloud-Based E-Mail 

Cloud-based e-mail means outsourcing e-mail service in its entirety to a 
cloud-based provider including hardware, software updates and licensing, security and 
patching. Outsourcing e-mail services minimize the e-mail footprint; reduce 
administration cost; facilitates user mobility; and allows organization tier structure, to 
tailor e-mail accounts to user needs including: mailbox size, mobile messaging, message 
filtering, licensing and updates. The cloud-based concept is illustrated in Figure 24. 
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Figure 24. Cloud-Based e-mail (From Microsoft Technet, 2010) 


A Forrester report published in 2009, reveals web based e-mail has much 
lower cost than e-mail with an on-premise e-mail client. On-premise e-mail costs a 
company $302.16 per user/year compared to roughly $50 per user/year the U.S. Army 
will be paying the first year of transitioning to a cloud e-mail service (this cost is 
expected to decrease after the first year of service) (Serbu, 2011). The major cost 
difference is the storage growth fees, archiving, mobile access, equipment failures, 
staffing, provisioning, and ongoing maintenance costs. 

Some of benefits of cloud-based e-mail include a more predictable and 
manageable storage cost generally charged on a flat per user, per month basis; no initial 
upfront commitments for infrastructure, hardware or licensing, and lower ongoing IT 
costs; a easy and fast deployment time; full redundancy and 99.99% network availability; 
transparent, continuous top-of-the-line upgrades; scalability; built in antivirus and anti¬ 
spam protection; e-mail access anytime, anywhere from any authorized, CAC-equipped 
computer; only pay for what is used; and easy administrative web based control tools. To 
the end user, an enterprise e-mail would allow mailbox, contacts and GAL access 
anywhere in the world and from any network. 

Outsourcing the control and management of tactical military data to third 
parties on the cloud would result in loss of full control over data and processes and this 
lost is one of the primary roadblocks for the Navy to move its data to the cloud. The 
decision to implement outsourcing requires a trade off analysis between security and cost. 
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b. Hybrid E-Mail Model 

On-premises messaging and cloud-base e-mail are not mutually exclusive; 
they can co-exist to provide organizations with an optimized solution to meet its specific 
needs. A hybrid solution is a combination of services provided by an on-premise e-mails 
system augmented with the cloud. The model must be customized based on what makes 
security, cost and technical sense. 

There are two main hybrid combinations: First, some e-mail services run 
on-premise and some run in the cloud; mailboxes remain on-premise and the archiving, 
management, and inbound e-mail spam and virus filtering are moved to the cloud. 

Second, some users run on-premise and some run in the cloud; this hybrid 
model is designed to meet the needs of a diverse workforce by customizing user accounts 
and only providing what each user needs. It uses a tiered workforce model with three 
categories: mobile executives who need big mailboxes and mobile messaging (such as 
Embarkables users); information workers who need a dedicated e-mail client (most 
NMCI and ONE-NET users), but smaller mailboxes; and occasional users who don’t 
need big mailboxes or dedicated e-mail clients (IT-21 users) (Schadler, 2009). This 
model brings the ability to move mailboxes from the cloud to on-premise servers as 
needed. The ability to move mailboxes from the on-premise to the cloud and back allows 
Embarkables users to maintain their e-mail during and after deployments. 

Figure 25 illustrates a hybrid model using exchange on-premise service for 
mobile executives and information workers and cloud e-mail for occasional workers. 



2003 or 2007 “Hybrid Editiorfserver 

Figure 25. Hybrid e-mail model example (From Microsoft Technet, 2010) 


86 





Hybrid e-mail introduces challenges of its own: e-mail features may differ 
for cloud and on-premise mailboxes; hybrid e-mail adds complexity in managing 
compliance; challenges in seeing “free/busy” status on calendars in the other domain; 
administrative challenges; no GAL segmentation or hierarchical address book; no 
multiple on-premise AD forest; no public folders; and no OWA login capability 
(Schadler, 2009). 

Outsourcing e-mail services is not new to the DoD. In 2011, the U.S. 
Army began transitioning over 900,000 users to a DISA cloud for e-mail services. Some 
DISA cloud’s benefits include providing CAC authentication, sending e-mails with larger 
attachments than is currently allowed, providing 4 gigabytes of online e-mail storage for 
standard e-mail account holders, and 500 megabyte webmail accounts for those who 
don’t normally use Army e-mail to perform their duties (U.S. Army, 2011). 

E-mail is a mission critical application for any organization, including the 
DoD. Developing a cloud-based standardized Navy’s e-mail solution requires a top-to- 
bottom design approach and the implementation of systems engineering techniques 
including functional decomposition of all system requirements, traceability of functions 
down to system components to prevent any gaps or overlaps, regular stakeholder inputs 
and milestone reviews, and requirement validation to obtain the best solution possible. 

C. CHAPTER SUMMARY 

The Navy has made some key architectural decisions which have shaped the 
current network architecture, AD structure and Navy’s business portfolio based on the 
operational environment, requirements and constraints. As new emergent challenges and 
requirements drive the increased the complexity of the Navy’s operations, the PEO must 
better utilize current solutions and explore new technologies to meet the dynamic 
requirements while balancing cost, schedule and perfonnance. 

Leveraging and enhancing NMCI’s DSTB, PPS and two-way-trusts to develop an 
office-like solution to embarking units while accessing network solutions has its 
technical, programmatic and cost challenges but is a possible interim solution to the 
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problem of rapidly and seamlessly integrating embarking commands into IT-21, 
enhancing command productivity and efficiency. 

The author recommends further exploring new technologies such as hybrid e- 
mail, an evolving technology which has reached a mature state and has proved to be 
efficient and has resulted in cost savings to the private sector. 
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V. CONCLUSION 


A. INTRODUCTION 

“The mission of the Navy is to maintain, train and equip combat-ready 
Naval forces capable of winning wars, deterring aggression and maintaining 

freedom of the seas.” 

—Mission statement of the United States Navy 

Over 320,000 Navy active duty men and women and over 200,000 U.S. Marines 
serve this country and protect America and its citizens at home and abroad (Department 
of Defense Manpower Data Center, 2011). Their duty is to defend our freedom, maintain 
peace, provide relief and support policies around the world by rapidly and effectively 
responding to evolving threats to our national security by air, land, sea and cyber space. 

Approximately 67,000 of Navy members serve onboard ships, supporting Marine 
units and Airwings during scheduled and unscheduled deployments around the world. 
Identifying, preventing and promptly responding to any acts of war are imperative to 
protect the American people and assets around. This requires the ability to rapidly deploy 
military forces and effectively integrate into any environment, thus increasing 
information technology capability and enhancing mission effectiveness. 

As the Navy strives for network commonalty and alignment, immediate 
capabilities are needed to support deploying forces anytime, anywhere in the world. The 
deployables’ mission is to provide mobile Navy and Marine assets the ability to 
interoperate on diverse networks in multiple deployment scenarios (Rivera, Deployables 
STEAG Brief, 2009). The diversity of operational environments and the embarking 
commands result in Embarkables integration problems. 

This thesis analyzed the different Embarkables processes and identified 
contributing factors to the interoperability problems experienced by the Embarkables 
assets while integrating into the IT-21 environment. These findings are summarized in 
this chapter by answering the research questions, followed by final comments by the 
author at the conclusion of this chapter. 
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B. ANSWERS TO RESEARCH QUESTIONS 

1. What are Embarkables and What are the Challenges They Currently 
Face? 

Embarkables are the Navy and Marine assets, users and workstations, deploying 
from NMIC, ONE-NET and other ashore networks and integrating into the IT-21 
network. This thesis focused on NMIC and ONE-NET Embarkables only, other network 
assets connecting to the IT-21 environment were not considered in this research. 

The Embarkables requirements vary for each network: NMCI deploys to IT-21 
and ONE-NET, ONE-NET deploys to IT-21, and IT-21 does not deploy to any network 
but supports integration of assets coming from the other two networks. The 
Embarkables mechanisms (also called Deployables) facilitate asset mobility between 
these networks but require complex and time consuming IT processes to integrate into the 
IT-21 network’s topology due to interoperability deficiencies and lack of trusted 
relationships between the networks. Chapter II provided an overview of all Embarkables 
mechanisms currently employed by the Navy and Marines. Some of the challenges 
currently faced by these Embarkables mechanisms and the embarking users and 
workstations are: 

Lack of defined requirements for Embarkables: A composed list of clear 
Embarkables requirements and measurable perfonnance thresholds was not found. 
Requirements are defined at a very high level in the NMCI contract but are not specific 
enough to develop an enterprise solution. Therefore, PMW-205 and PMW-160 developed 
ground rules and Embarkables mechanisms to integrate ashore assets into the afloat 
environment. These processes were tailored by each region and by each network. 
Undefined and unclear requirements leave room for a technology and architecture 
variations and implementation of solutions. 

No requirement to test new solutions against Embarkables: Although 
networks leverage each other’s network solutions in terms of technology and design 
when feasible, they are not required to test and verify interoperability between networks. 
Due to this lack of interoperability testing requirements, network solutions are 
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engineered, tested and fielded without inputs from the Embarkables community, and 
without notification to the IT-21 network that a new solution has been deployed which 
could potentially impact asset integration, ft is common that during a deployment, the 
recently fielded solutions causes seat integration issues and the Unit IT, the Embarkables 
support team, and ship’s staff struggle identifying and fixing these issues in a timely 
manner. 

Variations in the Embarkables process: Variations in the end-to-end 
Embarkables processes generate ongoing challenges due to inconsistencies in 
workstations’ readiness state to integrate, differences in capabilities, by command or by 
embarking unit, in network servers and storage capabilities , insufficient unit IT support 
for the size of the embarking command or IT staff unfamiliarity with the process. At 
times, the Marines leverage the pennanently installed and pre-con figured PPS suite as 
part of the ship’s forest, and at other times they bring their own servers suite. The 
Airwings bring their own Embarkables server and are provided their own forest. Other 
users embark without a server suite and connect directly into the 1SNS system. NMC1 
and ONE-NET have automated some part of the Embarkables processes by deploying the 
DMT. Although NMC1 and ONE-NET DMT tools provide similar functions, they 
provide a variation of capabilities to the Unit IT and the end user resulting in variation of 
the pre-deployment process and provide different level of visibility of the Embarkables 
assets to the Unit IT’s. 

Seat integration a time consuming process: Though Embarkables processes 
were partially automated with the introduction of the DMT, they have failed to keep up 
with the fast deployment of new solutions by the ashore networks. Some of these 
solutions impede and limit asset integration into the IT-21 environment, such as HBSS, 
and remain a labor intensive and time consuming integration procedure. The average time 
spent integrating an ashore seat into IT-21 is 45 minutes, assuming no problems, and does 
not include the intensive workload and time consuming coordination prior to each 
deployment. 

Commands unfamiliar with the Embarkables process: Commands that do not 

normally deploy and are unfamiliar to the deployables process, sometimes attempt to 
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bring equipment not listed in the IT-21 ISNS Preferred Products List (PPL) and that not 
are allowed to be integrated into the LAN. Many times those commands embark without 
a Unit IT for support, therefore depending on the already busy ship’s staff for IT 
assistance. This gives the perception that the Embarkables processes are broken and 
potentially results in negative advertisement. 

2. What are the Requirements for the Deployed Users/Systems for each 
Network? 

Other than high level requirements on the NMCI contract, there are no specific 
requirements on what IT services or capabilities Embarkables assets must obtain during a 
deployment. Solutions were developed and implemented to support the war fighter 
assuming a ‘seamless’ user experience when connecting to IT-21. Chapter II identified all 
services obtained by users when connected to their native network. These services were 
compared to the services received during a deployment for three different scenarios 
represented by user cases. Using the most common scenario, when embarking unit brings 
storage servers onboard, the IT services were grouped based on availability when 
connecting to the ship’s network. 

Seamlessly obtained services and capabilities during a deployment are limited to: 
the ability to logon to the local workstation, access MS Office and other applications 
previously loaded on workstation, access to hard drive data including e-mail archives and 
.pst files, and the ability to copy files to external media and reproduce CD/DVDs. 

Services and capabilities that require network reconfiguration or depend on the 
host network to function included most of the IT services: network access, e-mail and 
calendar capabilities, print/scan/fax, chat, access to home drives, command share data 
and portals, VTC, and file transfer. Other functions transparent to the end user but 
required to maintain seat security posture include: OS and application patching, backup 
and restore capabilities, remotely receive applications, and push of required security 
policies. 
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Other services and capabilities that are completely lost throughout the deployment 
period include: access to home network GAL and contacts, ability to digitally sign e-mail 
and access to public folders. 

Based on the gaps of services available during deployment, a function-to- 
component traceability matrix was performed to identify possible root causes of those 
problems, further explained in the following research questions. 

3. What is the Impact of Different Desktop Configurations? 

Afloat and ashore networks have customized Windows-based images which are 
not compatible with each other. Each desktop image baseline includes above core 
applications which are unique for the environment each network supports; business 
management applications which are mostly COTS and therefore compatible; enterprise 
software management agents which are different and incompatible among the three 
networks; and security and information assurance software such as an IA required 
Antivirus solution, for which each network runs a different product. 

Network management agents point to specific servers, such as the network patch 
repository and to the ePO server for HBSS, to obtain security updates and maintain 
desktop image compliance. These agents constantly access the patch repositories for 
latest OS and application patches to remediate network vulnerabilities to abide by DISA 
policies. These agents must be disabled during deployment, halting the ability to receive 
patches remotely from their native network. These seats must leverage the IT-21 patching 
process when feasible or perform manual patching throughout the duration of the 
deployment. 

Although NMCI and ONE-NET workstations have their own network image, they 
are capable of joining the ISNS domain and stay connected without having to be 
reimaged with the COMPOSE load. They do require to be manually joined to the 
Embarkables domain, to have proxy and exchange settings point to the ship’s servers, and 
have settings reconfigured to receive patches according to the patch management process 
used on the ship. 
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4. What are the Network Management and Architectural Differences? 

By performing a functional decomposition, function-to-component traceability 
matrix and an Ishikawa diagram, the following network management and architectural 
differences were identified: 

Variation in network management tools: Each network uses different vendor 
tools which are not compatible among themselves. These tools were selected due to the 
difference in operational requirements: (1) IT-21 tool does not need to support tiered 
network architecture or to patch non-Windows servers, while NMCI and ONE-NET do; 

(2) ONE-NET has a requirement to minimize the amount of agents installed on a seat to 
perform multiple management functions and the requirement for a scalable of product; 

(3) NMCI had a requirement to obtain user authorization for remote control of 
workstation which led to the use of an additional tool, NetMeeting. 

These additional requirements for the ashore networks led to the selection for 
Radia for NMCI and Tivoli for ONE-NET. IT-21 selected SCCM, the least complex and 
most cost effective solution (at the time of selection) to manage their network. 

Security compliance by network management and implementation of policies 
are incompatible: An important element of network management is patch management. 
This thesis identified the different patch management processes and the possible 
contributing factors to the inability of workstations to be seamlessly patched and the 
current issues the Embarkables face to get patches during deployment. During the 
brainstorming process to identify potential root causes leading to the problem (effect), 
major causes were broken down into sub-causes to identify relationships between the 
effect and all the possible causes directly or indirectly influencing the outcome. The 
following sub-causes are influences in most of the major categories: dissimilar AD 
structures; management tool interoperability; different processes; and undefined 
requirements. 

Deeper analysis into the patch challenges identified that the manual download of 
afloat patches during deployment is one of the causes of the inability to patch 
Embarkables seats: the size of patches is too big to download via SATCOM; low 


94 



bandwidth, high latency and intermittent connection causes patch downloads to fail; Unit 
IT must manually search for patches that apply to the Embarkables seats which is time 
consuming and could result in the wrong patch attempting to be applied; the U-Patch 
utility is available to NMCI seats for patching but still requires the manual download of 
patches into the source directory and initial configuration of all workstations to point to 
this source directory; and onboard LAN traffic is also limited, therefore distributing 
patches onboard the ship is limited to few seats at a time. 

Upon completion of the deployment, the assets must be up to baseline to 
reintegrate into the native network. Rather than verifying that all patches are up to date 
and that only approved applications are loaded on each workstations by performing visual 
inspection and comparing to image information for that each specific seat, some ashore 
commands opt to re image the workstations prior to allowing them to re-join their home 
network. 

Directory services structures: NMCI and ONE-NET directory services 
structures share similarities as both are composed of centralized active directory services 
for domain management, with logical structure of one forest for the entire enterprise, with 
trees and domains in a similar hierarchical organization and domain meshed models. 
Deploying multiple domain controllers in one domain provides fault tolerance and load 
balancing so failover capabilities provide enterprise support if a DC slows, stops, or fails 
since they contain the same directory data. This model provides centralized identification 
and authentication control allowing user mobility between logical and physical sites. 

IT-21 structure on the other hand, is a single AD forest per ship (multiple forests 
at the enterprise) to allow self-sufficiency when WAN connection is unavailable. Each 
ship carries its own forest root domain controllers to store domain-wide directory data 
(such as system security policies and user authentication data) and manage user-domain 
interactions, including user logon processes, authentication, and directory searches 
(Microsoft Technet, 2010). 

Embarking units cannot get authenticated and authorized by the ship’s DC as 
there is no trust between ship’s domain and the ashore domains. An Embarkables forest, 
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including user accounts and all Embarkables objects, must be created and a two-way-trust 
established with the ship’s forest in order access ship’s local resources such as printers 
and to receive transport services via SATCOM. 

This decentralized, multi-forest network management model, although more 
secure than a single AD forest, meets its purpose of providing data isolation and prevents 
network asset mobility or integration from any other domain. 

Current Navy networks operate in different environments with unique 
requirements. They are not interoperable and therefore a seamless integration of assets 
from one network to another is not feasible. 

5. How can the Navy Users Better and More Quickly Integrate Their 
Deployed Systems into Afloat Domains? 

The author provides two recommendations for better and faster integration of 
ashore assets into the shipboard environment by (1) including an Embarkables test for ah 
solutions prior to fielding to the operational environment, and (2) adapting existing 
solutions to provide “office like” services to embarking users. 

Establishing the requirement to test ashore solutions on a simulated afloat 
environment will aid identify interoperability issues on a test atmosphere and have the 
issues resolved prior to deployment. Testing should simulate the integration of an NMCI 
or ONE-NET workstation into an IT-21 domain by testing the technical aspects as well as 
the process flow involved in the integration of the seat. 

The second recommendation is adapting NMCI’s DSTB to VPN to the home 
network for patches, security upgrades and policies, combined with the pre-position 
servers or the Airwing Embarkables servers for local network shared data and exchange 
capabilities, and establishing two-way-trust between the embarked unit domain and the 
ship’s domain to access local resources such as printing, ship hosted applications and 
portals. Together, these solutions could potentially provide an “office like” experience to 
embarking users and workstations would be managed and maintained with latest OS and 
application patches by their own network, eliminating the need to reimage post 
deployment in order to reintegrate into the native network. An estimated cost of $228,621 
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to include initial DSTB procurement cost, monthly maintenance cost and technical 
support for six deployments in a four year period, could result in 3,800 man-hour savings 
and would minimize loss of data and loss of productivity by requiring minimal or no 
integration efforts to connect into IT-21 during deployments. 

6. How can Seamless Access to Navy E-mail be Achieved? 

Seamless e-mail is achievable by the implementation of a common Navy or DoD 
e-mail enterprise service architecture. A common e-mail enterprise service architecture 
would allow the access and exchange of electronic messages from anywhere in the world 
connected to the World Wide Web. Achieving a common Navy e-mail would require 
reengineering the current network and directory services architecture or moving e-mail to 
the ‘cloud’ by outsourcing e-mail services to a third party. Regardless of the selected 
approach, it will not be an easy undertaking and must be carefully evaluated. 

Relinquishing control of military tactical and strategic data to a third party 
requires extensive risk analysis, especially for IA considerations and due to the inability 
to have full visibility of the network and security enforcements on sensitive and classified 
networks. Recognizing the cloud’s dependency on the underlying network and how vital 
network survivability is for DoD mission, this risk would be a major area of 
consideration for DoD decision makers. Another consideration is the Navy’s afloat 
unique SATCOM environment; low bandwidth and intennittent link will limit the access 
to exchange of data internally and externally. 

Commercial technologies provide a hybrid models consisting of e-mail residing in 
the cloud and on-premise. This appears to be a more promising model if the intent for the 
government is to continue maintaining control of enforcing strict security policies while 
allowing more flexibility and mobility of user data, rather than transferring full control to 
a vendor. One of the hybrid models that is best suitable to support Embarkables is an 
architecture where some user mailboxes are on the cloud and some are on the on-premise 
servers. With this model, mailboxes can be moved from the on-premise servers to the 
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cloud for users on the move and during deployments; it allows scalability of size of 
mailboxes, such as smaller mailboxes for IT-21 users and other ashore users with limited 
need of e-mail usage. 

Due to the uniqueness of DoD requirements, a tailored solution might be the right 
approach by applying commercial concepts on DoD internal networks to create “private” 
cloud offerings, enjoying many of the benefits of cloud computing such as more rapid 
and dynamic resource provisioning, but probably not resulting in the same economies of 
scale. This approach has been implemented by DISA providing a cloud solution for the 
Army. This ongoing pilot effort to exercise cloud technologies on real-world DoD 
networks is being closely watched by other services for future adoption across all DoD 
(Serbu, 2011). 

C. CONCLUDING SUMMARY 

The Navy has successfully delivered, operated and sustained IT networks to 
support DoD’s mission and maintain communications superiority and dominance. These 
systems have advantages in reliability, maintainability, usability, supportability, and 
affordability characteristics but are deficient in other characteristics such as flexibility, 
adaptability, and portability. 

Navy networks have become large complex systems with relatively stable 
architectures and no standardization of technologies or protocols, with variation of 
security requirements, and with a centralized acquisition and management entity. The 
outcome is a variation of network solutions resulting in interoperability challenges and 
degradation/loss of communication efficiency. 

As DoD aligns systems and resources across organizations and military services, 
enterprise systems must be flexible, adaptable and reconfigurable. Whether developing 
new solutions or upgrading operational networks, system architects and engineers must 
implement a system-of-system approach and focus on developing dynamic 
reconfigurable system architectures (Williamson, 2012), with standardized protocols and 
technologies to enable adaptable and interoperable reliable systems to function anytime, 
anywhere. 
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APPENDIX: ASHORE NETWORK FUNCTIONAL 
DECOMPOSITION 


4.0 Enterprise Application Support Services 



4.1 Perform Briefing and Presentation Services 


4.2 Perform Calculation Services 



4.2.2 Calendaring 




4.2.2.1 Manage Appointments 




4.2.2.2 Shared Calendaring 



4.2.3 Perfonn Scheduling Tasks 



4.2.4 Perform Task Management 




4.2.4.1 Maintain Address Book 




4.2.4.2 Maintain Tasks 



4.2.8 Manage Desktop Communication Applications 



4.2.10 Conduct Instant Messaging 



4.2.11 Perform Real-Time / Chat 



4.2.12 Perform Real-Time Collaboration 



4.2.13 Conduct Video Conferencing 



4.2.14 Encrypt Data 



4.2.15 Manage and Manipulate File and File Systems 




4.2.15.1 Duplicate CDs 




4.2.15.2 Perform Data Compression 


4.3 Manipulate Documents 



4.3.1 Convert Documents 



4.3.2 Produce PDF Documents 



4.3.3 View Documents 



4.3.5 Perform Word Processing 


4.4 Produce and Manage Audio and Graphic Media 



4.4.2 Perfonn Desktop Publishing 



4.4.3 Support Development of Graphics 



4.4.4 Provide and Manage Clipart 



4.4.5 Support Development of Presentations 



4.4.7 Store and Retrieve Imagery 


4.7 Data Management Services 



4.7.1 Archive Data 



4.7.2 Conduct Data Storage/Retrieval/Updating 
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4.7.3 Conduct Database Queries 


4.7.7 Data Loadin 


4.7.10 Delete data 


4.7.11 Maintain data integrity_ 


4.8 Document Management Services_ 


4.8.1 Control Document Distribution 


4.8.3 Document Management 


0 Enterprise System Services 


5.1 Data Interchange Services_ 


5.2 Control Operation of Computer_ 


5.3 Provide Network Applications Services_ 


5.3.1 Detennine Equipment Availability_ 


5.3.2 Determine Equipment Capability 


5.3.3 Determine Equipment Performance 


5.3.5 Disseminate operational/tactical information 


5.3.5.5 Manage user profde 


5.3.5.6 Provide directory services 


5.3.6 Exchange electronic mail 


5.3.6.1 Create and edit messages_ 


5.3.6.2 Receive messages_ 


5.3.6.3 Send messages_ 


5.3.6.3.1 Allow users to send e-mails to multiple users (cc) 


5.3.6.3.2 Allow users to send e-mails with hidden send lists (bee) 


5.3.6.4 Manage Attachments 


5.3.6.4.1 Allow users to add file attachments to their outgoing e-mail 


5.3.6.5 Manage Inbox size 


5.3.6.5.1 Store incoming e-mail distinctly according to mailbox_ 


5.3.6.5.2 Store e-mail messages that have been sent_ 


5.3.6.5.3 Store incoming e-mail messages that have been read_ 


5.3.6.7 Manage Inbox e-mail folders_ 


5.3.6.8 Support Search capabilities_ 


5.3.6.9 Allow .pst creation 


5.3.6.10 Delete E-mails 


5.3.8 Provide network applications scalability 


5.3.9 Support web browsing 


5.4 Provide Network Services 


5.4.2 Compress data 
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5.4.4 Dynamically switch/route unicast (point-to-point), multicast and broadcast 
traffic across multiple networks_ 


5.4.4.1 Identify potential data transmission paths_ 


5.4.4.1.3 Establish connection-oriented network services 


5.4.4.1.8 Maintain network-related information 


5.4.4.1.9 Manage network operations 


5.4.4.1.9.1 Automatically generate and display network status 


5.4.4.1.9.2 Conduct performance management 


5.4.4.1.9.3 Perform account management 


5.4.4.1.9.4 Perform automated fault management 


5.4.4.1.9.5 Perform dynamic configuration management_ 


5.4.4.1.9.5.4 Manually configure/reconfigure the network_ 


5.4.4.1.9.7 Perform network information assurance/security 
management 


5.4.4.1.9.7.1 Authenticate user access 


5.4.4.1.9.7.2 Ensure data/information confidentiality 


5.4.4.1.9.7.2.1 Decrypt information/data 


5.4.4.1.9.7.2.2 Encrypt information/data 


5.4.4.1.9.7.3 Ensure non-repudiation_ 


5.4.4.1.9.7.4 Maintain data file integrity_ 


5.4.4.1.9.7.5 Prevent opportunity to attack_ 


5.4.4.1.9.8 Perform technical control of network 


5.4.4.1.10 Perfonn dynamic data transmission path selection 


5.4.4.1.10.1 Establish redundancy in the network to avoid single-point 
failures 


5.4.4.1.11 Provide network access scalability_ 


5.4.4.1.12 Provide network services scalability_ 


5.4.4.1.13 Synchronize network timing_ 


5.4.4.1.14 Terminate network connection 


5.4.5 Provide Networking Desktop Services 


5.4.5.1 Provide Directory Services 


5.4.5.2 Share Files and Printers 


5.4.5.3 Provide File Transfer 


5.4.5.4 Provide Message Services 


5.4.5.6 Provide Remote Access 


5.5 Provide Transport Services_ 


5.5.5 Interface with Local/Wide Area Networks 


5.5.6 Maintain appropriate level of security during data transmission_ 
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5.5.17 Access Control 



5.5.18 Role / Privilege Management 



5.5.19 User Management 



5.5.20 Data Verification 


5.6 Storage Management 



5.6.1 Backup 



5.6.2 Data Archiving 



5.6.3 Enterprise storage resource management 


5.7 Manage Databases 
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